Archived

This forum has been archived. Please start a new discussion on GitHub.

is there a timeout during checkedCast?

leya
leya
in Help Center
we are using windows xp, when the server machine is power off or server is closed behind a firewall, it will take like 40 sec for client to catch the exception.
it seems like when program goes to 'checkedCast', it blocked, i guess it is because of the firewall, this is normal, but still i need to know if there is a timeout during checkedCast so that we can shorten the waitness.

thanks:)

Comments

  • marc
    marc Florida
    checkedCast behaves just like any other operation call send to the server, i.e., it will use whatever timeout you have selected for the proxy.
  • leya
    leya
    thanks, marc

    i've tried on this:
    proxy=A::B::checkedCast(communicator->stringToProxy(string)->ice_timeout(5000))

    it works, but lasted for 10 sec, exactly two times, when change it to 2500, it waited for 5 sec. interesting:)
  • marc
    marc Florida
    This is correct. You can also set global timeout overrides with the Ice.Override.Timeout and Ice.Override.ConnectTimeout properties. Since checkedCast is quite often the first call to your server that initiates the connection, you might want to use the latter override. Please see the manual for details.
  • leya
    leya
    i got it, :) thank you very much~
  • marc
    marc Florida
    leya wrote:
    it works, but lasted for 10 sec, exactly two times, when change it to 2500, it waited for 5 sec. interesting:)

    This is expected behavior, since Ice will retry the operation call once by default. You can see this if you enable retry tracing.
  • rc_hz
    rc_hz
    Though the behavior can be explained, I think it is strange! That is, if the programmer significantly uses the timeout operation, Ice need not to retry the operation call as if it usually does.
  • marc
    marc Florida
    Ice considers timeouts fatal connection errors, and therefore timeout exceptions are retried just like any other connection failure. If it wouldn't retry upon connection timeouts, you couldn't build redundant servers, i.e., if Ice cannot connect to the 1st server within a given timeout, I expect it to try the next. If you only have one server, and don't want Ice to retry, you can always disable retries.
  • rc_hz
    rc_hz
    Another two questions:)

    1.
    Timeout can be divided: ConnectTimeoutException and TimeoutException
    1)ConnectTimeoutException: If a connection cannot be established within the specified time, this type of timeout is raised.
    2)TimeoutException: If a request times out, this type of timeout is raised.

    so, are the following understanding right ?
    1)ConnectTimeoutException: The Ice run time will automatically retry when it gets a ConnectTimeoutException.
    2)TimeoutException: The Ice run time can not retry the request when it gets a TimeoutException, otherwiase, at-most-once semantics will be broken.

    2. 
    Ice 3.1.0 manual says(Page 957):
The Ice run time may close a connection for many reasons:
? When deactivating an object adapter or shutting down a communicator
? As required by active connection management (see Section 34.4)
? When initiated by an application (see Section 34.5.4)
? After a request times out (see Section 34.3.3)
[COLOR="Blue"]Except when an application requests a forceful closure, the Ice run time always
closes a connection gracefully as required by the Ice protocol.[/COLOR]
    According to the above, when a request times out, the Ice run time will close the connection gracefully. But I think when a request times out, the Ice run time should close the connection forcefully because the Ice run time does not retry the request and the other outstanding requests on the same connection also time out.

    Thank you!
  • marc
    marc Florida
    This is a bug in the manual. If the application explicitly requests a forceful connection closure, the connection is closed forcefully. If the application requests a graceful connection closure, it is closed gracefully. For timeouts, the connection is always closed forcefully.

    Note that TimeoutExceptions may also be retried, for example, if the timeout occurs during sending the request, or if the operation is idempotent or nonmutating.

Categories