On 13 July 2011 09:49, Sven Van Caekenberghe <[email protected]> wrote: > Hi Igor, > > On 13 Jul 2011, at 00:00, Igor Stasenko wrote: > >> i think on time out it should verify that socket are still connected >> and try again. >> Or, add a check that if image is in non-interactive mode, ignore >> timeout and keep waiting for longer till socket will be closed by OS. > > Note that as far as I understand it, ConnectionTimedOut also applies to the > situation where the other side simply does not start the conversation, like > when trying to connect to the wrong port on an existing host. > > As things are now, timeouts are under the control of the client/user. > > There is a kind of global timeout ZnNetworkingUtils > class>>#defaultSocketStreamTimeout that can be set globally with > ZnNetworkingUtils class>>#defaultSocketStreamTimeout: seconds. The current > default default is 30. > > This default is used by a DynamicVariable called ZnConnectionTimeout. This > allows you to override the timeout on a per request / per process basis even > if you do not have access to the HTTP client yourself (like with MC) where > there are also options to change the timeout, of course. > > ZnConnectionTimeout value: 3600 during: [ ... ] will give you a one hour > timeout. I am using that to actually shorten the default timeout ;-) If a > server does not answer in 10 seconds, it most probably never will and I hate > waiting. >
well, the problem that it doesn't works as expected. Jenkins still failing with timeout and walkback shows that its 30 seconds. While code says 1 hour: https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Kernel/loadCore.st > There currently is not option for indefinitive timeout, apart from something > silly like SmallInteger maxVal or 52 weeks asSeconds. But do anyone really > want to wait a year for a timeout ? > > Anyway, timeouts and other exceptions are just part of networking, the > network is unreliable. > > Sven > > > -- Best regards, Igor Stasenko AKA sig.
