Archived

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

Timeouts on AMI calls?

mathewm
mathewm
in Help Center
Can you assign a timeout to an AMI call? It seems like you could leak callback objects if a server was not responding. It would also be nice to have a timeout method in the callback class to perform an alternate action.

I am new to Ice, so I was wondering if this type of functionality can already be easily implemented with the existing API, or if changes to Ice are needed.

Comments

  • mes
    mes California
    Hi,

    Timeouts are supported for asynchronous invocations. If a timeout occurs, the ice_exception method of your callback object receives a TimeoutException.

    Take care,
    - Mark
  • mathewm
    mathewm
    So how do you set the timeout for AMI calls?

    I took the Printer example from the document, and added a sleep(1) inside printString. I set a 10ms timeout on the client proxy, and if I do a normal call, it times out as expected. If I change to AMI, it does not call my ice_exception() and it eventually (after 1 second) does call ice_response().

    Is there a different timer for AMI calls?
  • mes
    mes California
    You set the timeout in the usual way, using ice_timeout on the proxy. However, you may have neglected to set the Ice.MonitorConnections property, which activates a background thread to monitor AMI timeouts.

    I just tried an AMI variant of the hello demo and it worked correctly. Let us know if you're still having trouble.

    - Mark
  • mathewm
    mathewm
    Thanks

    That is it. The default is no ConnectionManager, and so AMI calls effectively have no timeout by default. One problem I have with this is that the ConnectionManager interval is in seconds. This means that AMI calls will receive timeouts up to 1 second late.

    For the task at hand, I need the main thread to be able to send out some number of requests, then perform some other work. When the main thread's work requires the results from a particular server, I want it to block until either the response comes back, or the timeout expires. For this application I could cope with += 10ms, but a full second is too much.

    For me, I think I can just add an accessor to OutgoingAsync for the _absoluteTimeout value. This will allow the main thread to sit on the pending request for the correct amount of time before deciding to cope without the delayed data.

    Does this make sense? I want to be sure I really need to fork my copy of Ice.
  • mes
    mes California
    Given your timing requirements, perhaps your main thread should simply start worker threads that make synchronous invocations. When the main thread is ready to block, it could join with the worker threads and thereby ensure that all requests have succeeded or timed out.

Categories