Ice::ConnectionTimeoutException don't work same after upgrade since Ice 3.5 to 3.7

josedavid

Hi,

I have a python server-side app, with icestorm, and I have noticed a change in the timeout that affects the behavior of the application after updating from Ice 3.5 to 3.7.

Before, when one endpoint tried to connect with another, if the second endpoint lost the connection to the network once the server already had its proxy, when trying to connect, the timeout exception was immediate. Now, the timeout is NOT immediate (it seems that it never occurs, at least in a short period of time) and leaves the server caught, without working, without dispatching the rest of requests from other endpoints. Once the second endpoint is reconnected to the network, the timeout exception occurs.

I have a production environment that I want to update to 3.7 and this behavior is not acceptable, I would like it to behave the same as in 3.5.

In the code, the proxy ice_timeout is set to 3 seconds and i use to pairing both enpoints passing to the endpoint (that lose the network in this case) some data for the other enpoint:

ep1_id, subscriber_prx = self._tokens_in_use.pop(token)
subscriber_prx = subscriber_prx.ice_timeout(3000)               
pairing_id = str(uuid.uuid1())
subscriber_prx.linkDevice(ep2_id, ep2_name, pairing_id)

Is there any configuration parameter to set in the server layer or code method so that it works the same as before?

Thanks.

benoit

Hi,

You should check the 3.6 release notes for information on the timeout changes, see https://doc.zeroc.com/ice/3.6/ice-release-notes/upgrading-your-application-from-ice-3-5#id-.UpgradingyourApplicationfromIce3.5v3.6-Timeoutchanges

Setting Ice.Default.InvocationTimeout=-2 should provide the previous behavior. It isn't clear from your description if this will solve your issue however. Let us know how it goes after this change.

Once it works, I recommend considering changing to the timeout semantics.

Cheers,
Benoit.

josedavid

Hi,

I had not seen this point during the upgrade...

The "invocation timeout" solution is good and the specific proxy timeout is correctly applied again.

Thanks!