Question regarding IceBox / server side

ctennis

One question I've been wondering about as I'm exploring ICE for one of our projects is how to handle a server interface change ( such as that of IceBox) for multiple clients without causing problems for those clients.

Here's an example: we have 10 (identical) clients that will be making use of a server program most likely using IceBox.

Now let's say that we decide we need to add feature X to the server and clients. In order to do a quick test, we decide to implement this at one client and the server. We end up having to restart the server to do this. How does this impact the other 9 clients, who may actively be using the server at the time?

I know we'll get exceptions on those clients, but I'm curious if there's already some sugar already provided to handle server restarts without causing much havoc on the client side.

Is it possible to migrate clients using a IceBox server application over to another port or running instance of the server without them ever noticing? Or do we need to factor this type of things into the design of our clients?

Thanks for your thoughts.

bernard

Hi Caleb,

Welcome to our forums!

Using IceBox to implement your server is just an implementation strategy: it makes no difference to your clients.

Typically, when you add and test a new feature to an existing server, you would start a separate server instance on a different computer, or at least configure the new server's object adapters to use different ports. It's not clear to me why you would touch your production server for a "quick test".

Then, once your new server is ready, tested and up-and-running, you could let the running clients talk to the old server (until all these clients exit), and direct all newly started clients to the new server. This is fairly straightforward to do with IceGrid.

Best regards,
Bernard

michi

If you are interesting in graceful versioning of an application, have a look at at Issue 8 of Connections. It contains an article about using facets for versioning.

Cheers,

Michi.

ctennis

Thanks for your responses. I just read the link about using facets for versioning and I definitely see some information that is very valuable.

I'm still curious about stopping and starting a server, and the impact it has on multiple clients (let's forget about versioning for a second).

I know that if the server closes, the clients will throw an exception (I'm not sure if it's immediate or if it 's when they attempt their next communication).

However, is there an easy way to configure clients to alter their behavior - say tell them to wait 10 seconds before throwing an error - and inthe meantime attempt to reconnet.

Or perhaps is there a way to start up a new server on a new port, and send a message to the clients to seamlessly switch over to the new server and act like nothing has happened. After that, we can bring the old server down.

The reason I'm asking is that the software "clients" in our case will be computer programs that will be running basically 24x7 performing operations - so I have to plan in advance on how to handle starts and stops of various parts of their external communications.

Any thoughts you have are most appreciated.

Thanks,

beagles

You probably will find answers to some of your questions in the "Connection Management" and "IceGrid" chapters in Distributed Programming with Ice (aka the Ice documentation). The guys have described this stuff in the docs way better than I could here.

benoit

ctennis wrote:

However, is there an easy way to configure clients to alter their behavior - say tell them to wait 10 seconds before throwing an error - and inthe meantime attempt to reconnet.

Yes, it's possible to configure the number of retries and retry intervals that the client will use to wait before to retry. See the description for the Ice.RetryIntervals property in the Ice manual.

Or perhaps is there a way to start up a new server on a new port, and send a message to the clients to seamlessly switch over to the new server and act like nothing has happened. After that, we can bring the old server down.

You could indeed do this with the Ice location service. Basically, your clients would use indirect proxies (which don't contain any endpoint information) instead of direct proxies (which contain endpoint information). Your clients would obtain the endpoint information through the location service. When the old server would be shutdown your clients would contact again the location service to get the new endpoints of the updated servers. See the Ice manual for more information on indirect proxies, the location service and IceGrid (Section 2.2.2, 30.16 and Chapter 36).

Cheers,
Benoit.