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.
