Archived

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

Icegrid and Client/Server Communication Routing/Availability

We have a service that is loaded into IceGrid and started by IceGridNode on a machine with activation set to always. Sometimes, the service is unable to service requests due to reliance on a external resource but has state which needs to be held and deliver once the external resource is avaiable so our developers wrote something like the following:

if (!status)
{
adapter->destroy();
}
else
{
Ice::PropertiesPtr properties = communicator()->getProperties();
properties = communicator->getProperties();
adapter = communicator()->createObjectAdapter(iceAdapter);
id = communicator()->stringToIdentity(properties->getProperty("Identity"));
adapter->add(plat, id);
adapter->activate();
}

They also claimed that it worked in Ice 3.2 but it fails to work in Ice 3.5.

Some questions:
1) Would upgrading to Ice 3.7 help?
2) Is the claim valid?
3) Is there a way to route a service request to a specific server from the client? I don't see this in the documentation.
4) Is there a way to tell Icegrid that a service is temporarily unavailable and not route new requests to a server instance? I see something about holding requests from the server in the docs but nothing about temporarily making the server instance unavailable.

Let me know if you have any questions or comments.

Thanks,
John

Comments

  • benoit
    benoit Rennes, France

    Hi,

    Ice 3.2 and 3.5 are quite old now, upgrading would definitely be a good idea :smile:

    Without more information on the failure you are running into, I'm afraid it's impossible to say if upgrading to 3.7 would solve it and why it no longer works with 3.5. Could you provide a little more detail on what is failing?

    Regarding your question #3, yes if you deploy multiple servers and the servers are part of a same replica group and if the client uses a proxy with this replica group, the location service will return another server instance when a server instance becomes unavailable (because it destroys its object adapter for example like you do in your code). For more information on replica groups, see https://doc.zeroc.com/ice/3.7/ice-services/icegrid/object-adapter-replication

    As for your question #4, the IceGrid administrative interface allows to enable/disable servers. Disabled servers can continue running but IceGrid won't return endpoints for its adapters so clients won't use them. Enabling/disabling servers can be done using the icegridadmin CLI or the IceGridGUI. This functionality is also available through the IceGrid::Admin interface (see https://doc.zeroc.com/ice/3.7/ice-services/icegrid/icegrid-administrative-sessions for how to create an administrative session to get a hold on the IceGrid::Admin interface).

    Cheers,
    Benoit.

  • I realize that this is sort of in-depth and appreciate your help!

    I'll see about Ice 3.7 and see where that goes.

    From what I can tell, we are seeing a SIGKILL that might be initiated from the icegridnode process to the service application. From what I can infer:

    1) Our application is activated and ready to go. It uses the code above to reactivate the terminal.
    2) Our application detects an external resource is unavailable. A status flag is updated and in turn the adapter is destroyed.
    3) Our application detects the external resource is available again. A status flag is updated and in turn the adapter is activated again.
    4) A SIGKILL appears to be sent to the process.

    What we need is a way to continue having the process "up" so the state of the application can be kept and it can push forward the queued up stuff that it couldn't handle when it was invoked to be forwarded to the external resource. But we don't want it to service new requests and we don't want the process killed on the 2nd activate.

    The original developers thought that destroying the adapter and activating a new adapter would continue to do the following:
    1) Keep the process alive (no new PID)
    2) Make the service available again to IceGrid.

    That is the way they believe it worked in Ice 3.2 and doesn't work in Ice 3.5. I have no way of verifying that though.

    If the server application uses the IceGridAdmin API and does the equivalent of a server disable, does that mean IceGrid will no longer route requests to it (even though its still up)? I assume that is what your talking about. And if so, would the equivalent server enable bring it back up into the pool for serving new requests again?

    Thanks,
    John

  • Our original developer mentioned the use of hold from the server application as a possible solution. Would a client connecting to Icegrid be routed to that server for new requests be routed to that Ice Server?

  • Hi Benoit,

    As for your question #4, the IceGrid administrative interface allows to enable/disable servers. Disabled servers can continue running but IceGrid won't return endpoints for its adapters so clients won't use them. Enabling/disabling servers can be done using the icegridadmin CLI or the IceGridGUI. This functionality is also available through the IceGrid::Admin interface (see https://doc.zeroc.com/ice/3.7/ice-services/icegrid/icegrid-administrative-sessions for how to create an administrative session to get a hold on the IceGrid::Admin interface).

    This was very helpful! Duplicating the use of IceGrid::Admin from the Icegridadmin source code would be rather painful so I think I can do a system call to invoke the icegridadmin CLI.

    Best Regards,
    John

  • benoit
    benoit Rennes, France

    HI John,

    I believe the issue you are seeing is caused by IceGrid believing that the server is being shutdown because its object adapter is deactivated. We improved this in recent Ice versions to allow detecting when servers are shutting down and eventually kill them if the process doesn't go away after the server's configured deactivation timeout.

    You can disable this feature on the specific object adapter by updating your deployment and set server-lifetime="false" on the object adapter descriptor, see the documentation of the server-lifetime attribute for information on this.

    Cheers,
    Benoit.