Home Help Center

Connection management and ice_timeout (Ice 3.5.1)

grembogrembo Member Michael GmelinOrganization: Grem Equity GmbHProject: E-Commerce platform
Hi,

https://doc.zeroc.com/display/Doc/Connection+Management+in+Ice has the following example:
CommunicatorPtr communicator = ...;
ObjectPrx o = communicator->stringToProxy("hello:tcp -h remote.host.com -p 10000");
HelloPrx h1 = HelloPrx::uncheckedCast(o->ice_timeout(1000));
h1->sayHello();
HelloPrx h2 = HelloPrx::uncheckedCast(o->ice_timeout(2000));
h2->sayHello();

"In this case, h1 and h2 are bound to different connections because the timeouts of the two proxies differ."

It seems that this is always using different connections, even if ice_timeout is set to the same value:
CommunicatorPtr communicator = ...;
ObjectPrx o = communicator->stringToProxy("hello:tcp -h remote.host.com -p 10000");
HelloPrx h1 = HelloPrx::uncheckedCast(o->ice_timeout(1000));
h1->sayHello();
HelloPrx h2 = HelloPrx::uncheckedCast(o->ice_timeout(1000));
h2->sayHello();

^--- Still two connections.

It's only using the same connection, if the timeout is specified in the endpoint like this:
CommunicatorPtr communicator = ...;
ObjectPrx o = communicator->stringToProxy("hello:tcp -t 1000 -h remote.host.com -p 10000");
HelloPrx h1 = HelloPrx::uncheckedCast(o);
h1->sayHello();
HelloPrx h2 = HelloPrx::uncheckedCast(o);
h2->sayHello();

^--- Now the connection is shared.

My question is, if this is intended, stable behavior a design can rely on, or if this is a bug that will be fixed in a future release. A change in behavior can break things easily. I used ice_timeout in code (not specified in the endpoint) like invocation timeouts in the past, since in practice they actually worked like that (accidentally?), if the timeout was specified using ice_timeout. I started reading more about them recently due to the upcoming changes in Ice 3.6 and was quite surprised, that my current code actually works.

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    It shouldn't make a difference if the timeout is set on the stringified endpoint or programmatically on the proxy.

    Two proxies with the same timeout and endpoint should share the same connection unless connection caching is disabled (with the proxy ice_connectionCached method) and "remote.host.com" resolves to multiple IP addresses (in which case connection sharing is disabled and Ice will potentially open connections to any of the IP addresses that "remote.host.com" resolves to).

    Did you disable connection caching? You could also try to print out the connections associated with the proxies after the sayHello calls to verify if the connections are the same:
        cout << h1->ice_getCachedConnection()->toString() << endl;
        cout << h2->ice_getCachedConnection()->toString() << endl;
    

    Cheers,
    Benoit.
  • grembogrembo Member Michael GmelinOrganization: Grem Equity GmbHProject: E-Commerce platform
    Hi Benoit,

    Thanks for your quick response.

    Fortunately you're right, I was counting outgoing connections and always had two in my test code. This was due to me using "checkedCast" instead of "uncheckedCast" by accident, so the first connection wouldn't use an ice_timeout, and setting ice_timeout on the result would create a second connection using the timeout value. This didn't happen when the timeout was set through an endpoint specification (for obvious reasons), so it's all good.

    Cheers,
    Michael
Sign In or Register to comment.