[Pharo-project] Zinc time outs too fast
ConnectionTimedOut: Data receive timed out. 12 July 2011 10:39:11 pm VM: unix - i686 - linux - Squeak4.1 of 17 April 2010 [latest update: #9957] Image: Pharo1.4a [Latest update: #14034] [ConnectionTimedOut signal: 'Data receive timed out.'] in Socket>>waitForDataFor: Receiver: a Socket[connected] Arguments and temporary variables: .... Socket>>waitForDataFor:ifClosed:ifTimedOut: Receiver: a Socket[connected] Arguments and temporary variables: .... ZnHTTPSocketFacade class>>httpGet:args:user:passwd: Receiver: ZnHTTPSocketFacade Arguments and temporary variables: urlObject: 'http://www.squeaksource.com/Pharo/?C=M;O=D' queryArguments: nil username: '' password: '' url: http://www.squeaksource.com/Pharo/?C=M%3BO%3DD stream: SocketStream[inbuf:4kb/outbuf:4kb] request: a ZnRequest(GET /Pharo/?C=M%3BO%3DD) 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. -- Best regards, Igor Stasenko AKA sig.
Sig, With respect, that's almost correct. Sockets should not time out. Period. Clients can do so, but sockets should not. Servers should listen until they are told to stop doing so. One can do that iff socket calls block only the calling Process, which should also be the case. I am of the opinion that we have these features to enable workspace experiments, and they are hurting us. I'll shut up now :) Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Tuesday, July 12, 2011 6:00 PM To: Pharo Development Subject: [Pharo-project] Zinc time outs too fast ConnectionTimedOut: Data receive timed out. 12 July 2011 10:39:11 pm VM: unix - i686 - linux - Squeak4.1 of 17 April 2010 [latest update: #9957] Image: Pharo1.4a [Latest update: #14034] [ConnectionTimedOut signal: 'Data receive timed out.'] in Socket>>waitForDataFor: Receiver: a Socket[connected] Arguments and temporary variables: .... Socket>>waitForDataFor:ifClosed:ifTimedOut: Receiver: a Socket[connected] Arguments and temporary variables: .... ZnHTTPSocketFacade class>>httpGet:args:user:passwd: Receiver: ZnHTTPSocketFacade Arguments and temporary variables: urlObject: 'http://www.squeaksource.com/Pharo/?C=M;O=D' queryArguments: nil username: '' password: '' url: http://www.squeaksource.com/Pharo/?C=M%3BO%3DD stream: SocketStream[inbuf:4kb/outbuf:4kb] request: a ZnRequest(GET /Pharo/?C=M%3BO%3DD) 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. -- Best regards, Igor Stasenko AKA sig.
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. 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
On 13 July 2011 09:49, Sven Van Caekenberghe <sven@beta9.be> 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/Ker...
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.
On 13 Jul 2011, at 22:32, Igor Stasenko wrote:
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/Ker...
hmm, that should work. I'll add a unit test for ZnConnectionTimeout behavior tomorrow, just to make sure it works. Sven
On 14 Jul 2011, at 00:19, Sven Van Caekenberghe wrote:
I'll add a unit test for ZnConnectionTimeout behavior tomorrow, just to make sure it works.
I am pretty sure it works, the lastest Zn commits: Name: Zinc-HTTP-SvenVanCaekenberghe.174 Author: SvenVanCaekenberghe Time: 14 July 2011, 9:54:57 am UUID: bec35859-b638-42c1-9689-3f1d7a540c8b Ancestors: Zinc-HTTP-SvenVanCaekenberghe.173 ZnDefaultServerDelegate>>#echoRequest: added option to delay the response to /echo with a specified number of seconds, as in echo?delay=60 Name: Zinc-Tests-SvenVanCaekenberghe.87 Author: SvenVanCaekenberghe Time: 14 July 2011, 9:55:47 am UUID: d1f2d440-8420-4b11-84ec-d79bdc48e16b Ancestors: Zinc-Tests-SvenVanCaekenberghe.86 added ZnClientTests>>#testTimeout to test the correct working of ZnConnectionTimeout Both making the timeout shorter and forcing a timeout works, as in the test: testTimeout | server | server := ZnServer on: 1701. [ server start. self assert: server isRunning & server isListening. self should: [ ZnConnectionTimeout value: 1 during: [ ZnClient get: 'http://localhost:1701/echo?delay=2' ] ] raise: ConnectionTimedOut ] ensure: [ server stop ] As well as the other way around, waiting longer than the default timeout (I can't put this in the tests as it takes way too long for a unit test): ZnConnectionTimeout value: 50 during: [ ^ ZnClient get: 'http://localhost:1701/echo?delay=40' ] There could still be some deep problem somewhere (you say the default timeout of 30 shows up in stack), but as far as I can see this works. I have said this before, ConnectionTimedOut should in 99% of the case be interpreted as ResourceUnavailable, 30 seconds is an eternity for all but a small number of data or processing heavy requests. Sven PS: There is also always the option of extending the global default timeout ZnNetworkingUtils defaultSocketStreamTimeout: 360.
Thanks I will integrate them now.
I'll add a unit test for ZnConnectionTimeout behavior tomorrow, just to make sure it works.
I am pretty sure it works, the lastest Zn commits:
Name: Zinc-HTTP-SvenVanCaekenberghe.174 Author: SvenVanCaekenberghe Time: 14 July 2011, 9:54:57 am UUID: bec35859-b638-42c1-9689-3f1d7a540c8b Ancestors: Zinc-HTTP-SvenVanCaekenberghe.173
ZnDefaultServerDelegate>>#echoRequest: added option to delay the response to /echo with a specified number of seconds, as in echo?delay=60
Name: Zinc-Tests-SvenVanCaekenberghe.87 Author: SvenVanCaekenberghe Time: 14 July 2011, 9:55:47 am UUID: d1f2d440-8420-4b11-84ec-d79bdc48e16b Ancestors: Zinc-Tests-SvenVanCaekenberghe.86
added ZnClientTests>>#testTimeout to test the correct working of ZnConnectionTimeout
Both making the timeout shorter and forcing a timeout works, as in the test:
testTimeout | server | server := ZnServer on: 1701. [ server start. self assert: server isRunning & server isListening. self should: [ ZnConnectionTimeout value: 1 during: [ ZnClient get: 'http://localhost:1701/echo?delay=2' ] ] raise: ConnectionTimedOut ] ensure: [ server stop ]
As well as the other way around, waiting longer than the default timeout (I can't put this in the tests as it takes way too long for a unit test):
ZnConnectionTimeout value: 50 during: [ ^ ZnClient get: 'http://localhost:1701/echo?delay=40' ]
There could still be some deep problem somewhere (you say the default timeout of 30 shows up in stack), but as far as I can see this works.
I have said this before, ConnectionTimedOut should in 99% of the case be interpreted as ResourceUnavailable, 30 seconds is an eternity for all but a small number of data or processing heavy requests.
Sven
PS: There is also always the option of extending the global default timeout
ZnNetworkingUtils defaultSocketStreamTimeout: 360.
Pavel, Igor, On 14 Jul 2011, at 10:06, Sven Van Caekenberghe wrote:
There could still be some deep problem somewhere (you say the default timeout of 30 shows up in stack), but as far as I can see this works.
I have said this before, ConnectionTimedOut should in 99% of the case be interpreted as ResourceUnavailable, 30 seconds is an eternity for all but a small number of data or processing heavy requests.
Does it work now ? Sven
Hi Sven, On Fri, Jul 15, 2011 at 1:01 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
Pavel, Igor,
On 14 Jul 2011, at 10:06, Sven Van Caekenberghe wrote:
There could still be some deep problem somewhere (you say the default timeout of 30 shows up in stack), but as far as I can see this works.
I have said this before, ConnectionTimedOut should in 99% of the case be interpreted as ResourceUnavailable, 30 seconds is an eternity for all but a small number of data or processing heavy requests.
Does it work now ?
Yes, we added longer timeouts for download of package contents and it is working now well. Thank you. -- Pavel
Sven
On 13 Jul 2011, at 22:32, Igor Stasenko wrote:
While code says 1 hour: https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker...
There is also a typo: ZnConnectionTimeout value: 3600 during: [ gofer:= Gofer it squeaksource: 'Pharo14'. newPackages do: [:package | gofer package: package ]. ofer load. ]. The last statement says 'ofer load' instead of 'gofer load'.
Thank's for the report. As I see the timeout appears already in step when latests network and gofer packages are loaded so this code was not executed. I'll try to use longer timeouts there too. Cheers -- Pavel On Thu, Jul 14, 2011 at 7:33 AM, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 13 Jul 2011, at 22:32, Igor Stasenko wrote:
While code says 1 hour: https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker...
There is also a typo:
ZnConnectionTimeout value: 3600 during: [ Â gofer:= Gofer it squeaksource: 'Pharo14'. Â newPackages do: [:package | gofer package: package ]. Â ofer load. ].
The last statement says 'ofer load' instead of 'gofer load'.
participants (5)
-
Igor Stasenko -
Pavel Krivanek -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe