# Socket 10s hangs **URL:** \ **Category:** Ruby\ **Created:** [August 27, 2007, 10:22pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130 "2007-08-27T22:22:15Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 27, 2007, 10:22pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/1 "2007-08-27T22:22:15Z")
Question: anybody ever had the situation of a socket create or send that freezes all thread for multiples of 10s? (i.e. 10 or 20 or 30–exactly?) Odd, isn’t it? Thanks! [note this is tcp sockets to IP addresses, not hostnames, so it is most likely not a DNS latency] -Roger ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 27, 2007, 11:13pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/2 "2007-08-27T23:13:31Z")
Roger P. wrote: > Question: anybody ever had the situation of a socket create or send that > freezes all thread for multiples of 10s? (i.e. 10 or 20 or > 30–exactly?) Odd, isn’t it? Thanks! [note this is tcp sockets to IP > addresses, not hostnames, so it is most likely not a DNS latency] > -Roger Does it help if you do Socket.do\_not\_reverse\_lookup = true before you start using sockets? ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 28, 2007, 8:04pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/3 "2007-08-28T20:04:23Z")
I think that did it! Thank you! Where is the documentation for this stuff??? I assume that it does a reverse lookup on every socket? If that’s the case I might put in a request to ruby to only do reverse DNS when it is requested (lazily)…hmm… Joel VanderWerf wrote: > Roger P. wrote: > > > Question: anybody ever had the situation of a socket create or send that > > freezes all thread for multiples of 10s? (i.e. 10 or 20 or > > 30–exactly?) Odd, isn’t it? Thanks! [note this is tcp sockets to IP > > addresses, not hostnames, so it is most likely not a DNS latency] > > -Roger > > Does it help if you do > > Socket.do\_not\_reverse\_lookup = true > > before you start using sockets? ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 28, 2007, 8:34pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/4 "2007-08-28T20:34:24Z")
Roger P. wrote: > I think that did it! Thank you! > Where is the documentation for this stuff??? It is mentioned in the socket section in the Pickaxe (ed. 1 is on-line somewhere, ed. 2 is worth buying). But if you don’t know what you’re looking for that doesn’t help… It’s just one of those gotchas that keeps coming up. A similar one is Thread.abort\_on\_exception = true (otherwise threads die silently on unhandled exceptions). > I assume that it does a reverse lookup on every socket? If that’s the > case I might put in a request to ruby to only do reverse DNS > when it is requested (lazily)…hmm… IIRC, the reverse lookup only happens if you call something like sock.addr or sock.peeraddr, and you’ve left Socket.do\_not\_reverse\_lookup = false. ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 28, 2007, 9:26pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/5 "2007-08-28T21:26:33Z")
On Wed, 29 Aug 2007 03:33:04 +0900, Joel VanderWerf [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > It’s just one of those gotchas that keeps coming up. A similar one is > > Thread.abort\_on\_exception = true > > (otherwise threads die silently on unhandled exceptions). You don’t always want to do that, since you can recover the unhandled exception that terminated a thread via Thread#join or Thread#value and some libraries rely on this. -mental ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 28, 2007, 9:40pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/6 "2007-08-28T21:40:15Z")
Mental G. wrote: > On Wed, 29 Aug 2007 03:33:04 +0900, Joel VanderWerf > > > It’s just one of those gotchas that keeps coming up. A similar one is > > > > Thread.abort\_on\_exception = true > > > > (otherwise threads die silently on unhandled exceptions). > > You don’t always want to do that, since you can recover the unhandled > exception that terminated a thread via Thread#join or Thread#value > and some libraries rely on this. Interesting. I suppose I’ve never run into that. It helped me debug things, mostly, and seemed useful, though I suppose handling exceptions on join or checking value is another option. Thanks. -Roger > -mental ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 28, 2007, 9:30pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/7 "2007-08-28T21:30:07Z")
> IIRC, the reverse lookup only happens if you call something like > sock.addr or sock.peeraddr, and you’ve left Socket.do\_not\_reverse\_lookup > = false. And of course I had been. Silly me. Thank you! -Roger ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [August 28, 2007, 9:59pm UTC](https://www.ruby-forum.com/t/socket-10s-hangs/113130/8 "2007-08-28T21:59:37Z")
MenTaLguY wrote: > On Wed, 29 Aug 2007 03:33:04 +0900, Joel VanderWerf [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > It’s just one of those gotchas that keeps coming up. A similar one is > > > > Thread.abort\_on\_exception = true > > > > (otherwise threads die silently on unhandled exceptions). > > You don’t always want to do that, since you can recover the unhandled > exception that terminated a thread via Thread#join or Thread#value > and some libraries rely on this. Good point. It’s a global setting, so should be avoided. Better to set this flag on threads individually using the instance method #abort\_on\_exception and do so only in those cases where you don’t use join or value to propagate the exception to another thread. For example, it would be a good idea to set this flag for a thread that is expected to run indefinitely (no other thread is waiting for it to finish). Even in that case, you might want to wrap the thread’s code in a rescue clause, if you just want to log the error and let other threads proceed.