Ice Timeout Resolution

[shiv]

The Timeout section has a paragraph that says:

The timeout in effect when a connection is established is bound to that connection and affects all requests on that connection. If a request times out, all other outstanding requests on the same connection also time out, and the connection is closed forcefully (see Section 37.5.4). The Ice run time automatically retries these requests on a new connection, assuming that automatic retries are enabled and would not violate at‑most-once semantics (see Section 32.23).

Taken from last paragraph of http://www.zeroc.com/doc/Ice-3.3.1/m...ions.38.3.html.

Is there a way to retry those outstanding requests which have not yet physically timed out (and are forced to timeout because of one long request)? Or is there any way to stop all outstanding requests from timing out on the same connection when only one request on the connection has timed out?

Thanks, Shiv

[michi]

All the requests that time out and aren't retried raise a timeout exception. So, you can retry those requests explicitly by catching the exception and retrying. Keep in mind that doing so may violate at-most-once semantics because a request may have been dispatched to the server-side application code already and the timeout may happen while the corresponding operation is still in progress.

You cannot stop other requests on the same connection from timing out because the timeout closes the connection. If you want to prevent other requests from timing out, you can issue these requests on a separate connection by setting the connection ID. (See ice_connectionID in the manual.) Proxies with the same connection ID share the same connection, and proxies with different connection IDs use separate connections.

Cheers,

Michi.

[shiv]

Thanks. Your solution for using the connection_id can probably work for us. It is interesting that Ice assumes that timeouts are due to something wrong in the system and thus drops all requests on the same connection. Sometimes timeouts could be normal and happen for a small percentage of requests.

However, as I mentioned above, the connection_id tweaking will probably solve our problem.