Archived

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

Async proxy connect

hello
i wrote this post because i'm having some troubles with the connect mechanism ...
i'm developing an application that connect's to an ICE server but when doing so,
if the address of the server (or the server itself) are down, my applications freezes.
i need to know if there is a non-blocking way for a proxy to connect to the server ?
just like AMI works, passing it a callback object

Comments

  • bernard
    bernard Jupiter, FL
    Hello,

    You could use AMI for all your operations.

    What do you mean by "a proxy to connect to server"?

    Ice establishes connections automatically when you invoke an operation. You don't need to explicitly "connect" a proxy to the target Ice object.

    Which operation call is blocking your application?

    Best regards,
    Bernard
  • blocking execution

    the problem shows up when i try to connect to a the server that does'nt exist,
    te entire application slows down ...

    the app consist in a simple scada collector that uses loadable drivers, one of
    these drivers is the one that's giving me headache ... OPC.
    my app is developed using Qt4.4.2 and runs under Debian Lenny, thats way i can't
    connect directly to the OPC server, i need a gateway to do so. these gateway runs
    in win32 and serves the data through ICE (acting like a server)
    now, the driver just sends the request to the server (using AMI) and release the calling
    thread to allow the collector to keep working with the others driver ...
    then, when i configure the driver with an invalid gateway (ICE server) address, the collector slows down and eventually freezes

    that's the entire situation, thanks for any help

    PD: sorry about my english, i'm not very experienced with it
  • benoit
    benoit Rennes, France
    Hi,

    Which Ice version do you use? AMI calls are fully non-blocking only since Ice 3.3. Are you making non-AMI calls? Note that checkedCast calls are synchronous calls which might block, if possible you should consider using uncheckedCast calls instead.

    Are you using timeouts? If not, I recommend using them because some network operations might block for a very long time under some conditions (if a firewall drops the connection request for example). If you use AMI, this won't block the calling thread but this will nevertheless still consume resources and it will take a very long time for the AMI callbacks to be called by the Ice runtime.

    Also, did you try attaching the process when it freezes? Seeing the stack traces at this point should help to see where the process threads are blocked.

    Cheers,
    Benoit.
  • it seems that my only problem was using Ice 3.2.1 ...

    thanks all of you for the fast response !!!