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.