Archived

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

ObjectNotExistException in callback

Hi,

Background:
we have a Java client and a Java server. The communication uses the "Grim Reaper" pattern as explained in Issue3 of the newsletters (i.e. a factory to create a session). In addition, the client registers a callback with the server and the connection is bi-directional.

Problem:
We developed on Windows, where the callbacks worked properly. When we deployed our server on Solaris, the callbacks were not working anymore (we always got ObjectNotExistException as soon as a callback was invoked). After a few hours, we found out, that in the case of Solaris, the client uses two different connections: one for the factory and a different one for the returned session. naivly, we set the object adapter for the callbacks only on the factory connection because we expected there is only one connection due to connection reuse. As soon as we set the object adapter on the session connection, the callback worked again.

Questions:
1) What could be the reason that the number of connections is different for the same client but a different server platform/hardware?
2) Is it correct/expected, that the callback object adapter needs to be set on any proxy returned?

Thanks a lot, Stephan

Comments

  • benoit
    benoit Rennes, France
    Hi Stephan,

    See this FAQ about Ice connection sharing and the Connection Management chapter in the manual for information on how exactly connection management works with Ice.

    The most likely reason for your client to not re-use the same connection is that the server returns a proxy with a different timeout setting from the timeout setting of the proxy used to create the session. Try printing out the proxy of the session factory and the proxy of session to see what are the differences -- this should give you some clues on the reason why the Ice runtime establishes 2 connections.

    To answer your second question, yes you need to set the adapter on all the connections that might receive requests for your callback object.

    Did you consider using Glacier2 instead of using directly bi-directional connections? With Glacier2 you wouldn't have this issue.

    Cheers,
    Benoit.
  • Hi Benoit

    Finally, we found some time to investigate further. The timeout settings were really different because we did override the timeout setting in the server but not in the client. Thanks for the tip!

    At the moment, we don't user Glacier2 because this would need another component that must be installed, started, monitored and - in our case - licensed.

    Regards, Stephan