Graceful restart of icegridnode without failing client lookups possible?

AndiDogAndiDog Member Andreas SommerOrganization: PayPlusProject: PayPlus internal payment software

We want to restart several of our icegridnode processes to update both the configuration file (new IceSSL.Trust* properties) and update to 3.6.4 (see important fixes in changelog). Such a restart is very risky in production because while the process is restarting, client lookups to the registry will most probably not work. Is it possible for the registry to wait until the icegridnode is back up instead of immediately answering lookup requests with a failure (Ice::NoEndpointException)? Or do you other ideas how to keep Ice calls working while a node is shortly down?

Tagged:

Best Answer

  • benoitbenoit Rennes, FranceBenoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Accepted Answer

    Hi Andreas,

    It's not possible to tell the registry to hold on Ice client's lookup requests while the node is being restarted. If you want to prevent downtimes and still allow updating components running in the IceGrid domain, you should deploy multiple instances of your servers on 2 different nodes. This way, you can update the servers running on one node while the other node is still running.

    Cheers,
    Benoit.

Answers

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

    Hi Andreas,

    It's not possible to tell the registry to hold on Ice client's lookup requests while the node is being restarted. If you want to prevent downtimes and still allow updating components running in the IceGrid domain, you should deploy multiple instances of your servers on 2 different nodes. This way, you can update the servers running on one node while the other node is still running.

    Cheers,
    Benoit.

  • AndiDogAndiDog Member Andreas SommerOrganization: PayPlusProject: PayPlus internal payment software

    We also went in that direction. Because the application expected exactly one server instance, we "transferred" the server over to a new icegridnode process (by updating the application XML and running application update app.xml). That way, we could bring up a new icegridnode process, migrate the service over (without failing calls!) and later move the service back which would allow removing the temporary node.

    Thank you!

Sign In or Register to comment.