http::geturl intermittent hang - looks for ideas...
in [TCL]
|
Prev: socket limitations question
Next: file tempfile
From: Eric Hassold on 15 Oct 2009 17:57 Adrian Davis a �crit : >> The typical hang would be nameserver related, so if your DNS is not >> resolving, you can get longer hangs. One way around it would be some >> async DNS resolver. > > Michael, > > Unfortunately, I get the same problem when specifying the IP address > directly in the URL. > > Best Regards, > =Adrian= > Maybe are you faced this issue I reported in this group : http://groups.google.fr/group/comp.lang.tcl/browse_thread/thread/9a1a0b7f57141b12/3d834b2849323562#3d834b2849323562 with SF bug tracking Id http://sourceforge.net/tracker/index.php?func=detail&aid=1928131&group_id=10894&atid=110894 New http 2.7.x implementation, introduced in 8.5.x, adds support for chunk transfer in a non-asynchronous way. This is unfortunately implemented by forcing socket to switch into blocking mode before reading each (eventually large) chunk. This still applies to http 2.7.3, which is found in Tcl 8.5.7. See http.tcl line 1083: .... set bl [fconfigure $sock -blocking] fconfigure $sock -blocking 1 set chunk [read $sock $size] fconfigure $sock -blocking $bl .... This is very hazardous, since this will block until whole chunk is read. As a consequence, if anything unexpected happen on the net before read is completed, application is totally frozen, since event loop is never called again. Eric Hassold
From: tom.rmadilo on 16 Oct 2009 00:32 On Oct 15, 2:57 pm, Eric Hassold <hass...(a)evolane.com> wrote: > New http 2.7.x implementation, introduced in 8.5.x, adds support for > chunk transfer in a non-asynchronous way. This is unfortunately > implemented by forcing socket to switch into blocking mode before > reading each (eventually large) chunk. This still applies to http 2.7.3, > which is found in Tcl 8.5.7. See http.tcl line 1083: > > ... > set bl [fconfigure $sock -blocking] > fconfigure $sock -blocking 1 > set chunk [read $sock $size] > fconfigure $sock -blocking $bl > > This is very hazardous, since this will block until whole chunk is read. > As a consequence, if anything unexpected happen on the net before read > is completed, application is totally frozen, since event loop is never > called again. Strange, what is the purpose of using blocking mode in that situation?
From: Alexandre Ferrieux on 16 Oct 2009 02:44 On Oct 16, 6:32 am, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > Strange, what is the purpose of using blocking mode in that situation? If I were to guess, I'd say "to simplify the state machine" ;-) Now you're welcome to step in and rewrite that part, unless Jeff objects. -Alex
From: Adrian Davis on 16 Oct 2009 04:11 > Unplug your network cable, extend your timeout to over three minutes > (or maybe five) and see what the error message is for dns timeout. If > it doesn't differ from the original, you may not be able to rely on > the error message. But 60 seconds is less than required to test DNS > timeout. The main problem I have is that the geturl timeout is not doing anything. The geturl hangs - never returns - no error message. I'd be very happy indeed if setting the timeout to one minute actaully caused the geturl to timeout. Are there any other ways that I can force the geturl to quit after a specified time? Many Thanks, =Adrian=
From: Alexandre Ferrieux on 16 Oct 2009 04:40
On Oct 16, 10:11 am, Adrian Davis <adr...(a)satisoft.com> wrote: > > Unplug your network cable, extend your timeout to over three minutes > > (or maybe five) and see what the error message is for dns timeout. If > > it doesn't differ from the original, you may not be able to rely on > > the error message. But 60 seconds is less than required to test DNS > > timeout. > > The main problem I have is that the geturl timeout is not doing > anything. The geturl hangs - never returns - no error message. I'd be > very happy indeed if setting the timeout to one minute actaully caused > the geturl to timeout. > > Are there any other ways that I can force the geturl to quit after a > specified time? See Eric's post. He might very well have found the exact cause of your problem, namely a transitory blocking I/O, meaning a window where the event loop is not active (hence the timeout ignored). To be sure, please do what I've already suggested, use Wireshark. With the trace in hand we'll have unambiguous evidence in one way or the other (if Eric's mechanism is at play, we'll see a Chunked transfer start and stall within a chunk). -Alex |