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

How to notify a restart of Server to the client

I have Ice applications which have implemented callback. So basically client registers with the "stringified proxy" during the startup and server will initiate the callback on the proxy object during some event. I have a scenario where server is getting restarted. Now the client is unaware of it. So the registered stringified proxy is no more valid.

Is there a way a server can notify during a restart so that i can register the proxy again ? Or how do i handle this scenario?



  • Nooji
    edited September 2017

    Note: I am not using icegrid .. Using only icebox. Would like to know the solution in case of peer-peer(client-server ) situation.

  • benoit
    benoit Rennes, France


    This is typically solved using the session design pattern. The client establishes a session with the server and both monitor the liveliness of the session. When either the server or client detects that the session is dead, they can take appropriate action to cleanup the previous session and re-establish a new one (which might involve registering new callback proxies).

    The Ice/session demo from our demo repository demonstrates a way to implement sessions. You can also take a look at the design of our Chat Demo which also uses sessions.

    Note that there various way to implement sessions:

    • a simple one is to rely on the Ice connection, basically the session is bound to the Ice connection between the server and client. Both can register a callback to be notified when the connection is closed, when the connection is closed they can take appropriate action to cleanup their state and re-establish a new connection.
    • another possibility is to implement a session Ice object The client pings the object by calling a refresh operation regularly. If the ping fails in the client, it can assume that the server restarted or destroyed its session. The server can check whether or not the client calls the ping regularly (if not, it can assume the client is dead).

    It's difficult to say which solution best suite your needs without knowing more about your application.

    Btw, you mention that you are registering the callback proxies using "stringified proxies". Why do you pass proxies as strings? I recommend to pass the proxies directly, proxies can be passed as Slice operation parameters. For example, in our session demo, we return the proxy of the session Ice object.


  • Thanks for the reply. I think the first approach suits.. But what should be the strategy for reconnecting to the server?

    I have client requesting for a key from the server. On expiry of the key i wanted a callback from server to client. Implemented the same by passing the proxy from the client as a parameter and a method on the proxy object is called from the server(similar to Callback demo in ice repository). But the proxy will not be valid if the server restarts(because of whatever reason). That's the question basically!

    Is it possible to have a client retry enabled and on the successful connection , i will register the new proxy object again? By this i need not have my own re-connection logic and i need not have callback registered for drop in the connection(setCloseCallback) .. Will this increase ice messages ? Also what is the callback for successful re-connection?

  • benoit
    benoit Rennes, France


    Why is the client proxy no longer valid after the server restart? Is your server saving the proxy to a database? Does your client listens on a fixed endpoint (tcp endpoint with a fixed port number)?

    You need to decide on the connection strategy to adopt for callbacks from the server to the client, you have 2 possibilities:
    1. the client listens on an endpoint and accept incoming connections from the server to dispatch the callback
    2. the client doesn't listen on an endpoint and you use bi-directional connections to dispatch the callback

    With the first option, there are 2 connections between the server and client, the client established by the client to the server and the connection established by the server to the client. The server can save the proxy to a database and on restart it should be able to re-establish its connection to the client if the client is still listening on the same endpoint. The Ice/callback demo uses this strategy (you can enable Ice.Network.Trace on both the server and client to see the network connections).

    With the second option, there's a single connection between the client and the server. The network connection established by the client to the sever. The server re-uses this connection to call the callback on the client. Of course, when you restart the server, the connection goes down. Since the server has no way to establish a connection to the client, it is up to the client to retry the connection establishment to the server. Bi-directional connections are demonstrated with the Ice/bidir demo.

    Which option better suits your client/server needs?

    If you go for the first option, the server should be able to re-establish the connection the client to perform the callback. If you go for the second option, your client will need to use the setCloseCallback to be notified when the connection goes down and it will need to implement a retry logic to re-establish the connection to the server and register again its callback.


  • Nooji
    edited September 2017

    Thanks Benoit.

    I am already using Ice/callback method. We don't use any database currently and we are not in favor of the same. May be we catch this event using a shutdown-hook(java) and re-register the client once the server is UP. Is there a way i get to to know if the server is up through some event? Or i just have to keep polling ?

    One more question: when i run the demo, what database it uses and where is it stored and how to configure the same ?

  • bernard
    bernard Jupiter, FL

    The Ice/callback demo does not store any data and does not use a database. It's a very simple demo.

    When an Ice server comes "up" (typically meaning its object adapter is activated), Ice does not notify clients. How could Ice know which clients intend to contact this server?

    You have at least two options to reconnect to an Ice server:
    - your client attempts to (re)connect to your server in a loop until it succeeds (that's polling)
    - you use IceDiscovery in your client and server, and configure timeout and retries in IceDiscovery. See the IceDiscovery demos for examples.

    Best regards,