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.