[omniORB] How to handle server shutdown

[Nigel Rantor]

Toni Cebrián wrote:
> Hi,
> 
>    We have a problem trying to reach a server that has been shut down
> and restarted. The setup is as follow, we have a Client that access the
> NameService asking for the  server reference. It then stores the
> narrowed object for later access. Then I shutdown the server, I restart
> again, the server does a rebind in the NameService, and waits por
> connections. The server is started with de -ORBendPoint
> giop:tcp:my_machine:my_port option in the command line. The server is
> perfectly functional for other clients, but the former client isn't able
> to communicate with the server. It doesn't complain about anything, nor
> CORBA::Transient nor CORBA::COMM_ERRORs  when sending requests but the
> server doesn't manages the requests.

What do you see from the client side then? Are you sure you're not
swallowing some exception? I would expect something like INV_OBJREF to
be thrown...either that or my idea about what your problem is may be wrong.

> I supose that there is something
> I'm doing wrong but I can't see what.
>    The question is, which is the best way you make your clients fault
> tolerant to CORBA server failures? It seems that restarting the server
> listening in the same port doesn't work for me.

I think this is because you just found out that it's not just the
host/port combo that uniquely identifies a remote object.

There is more information in the IOR that tells the server exactly which
object within its active set this IOR refers to.

If you want an object to be accessible over repeated server runs then
you have to arrange to set this piece of information yourself.

You'll need to set the ID assignment policy to USER_ID in the POA you're
activating the servant in.

Then you need to decide on the exact ID to give it, but that's up to you
really, it's just an opaque bit of data to uniquely identify the object
within the context of the server.

I don't have an example laying around, but it's not too hard to get
these kind of servers running on well-known ports and a well-known
object ID so that they can be found repeatedly without multiple
CosNaming lookups.

The *other* option is to correctly identify when a remote object is not
available (see above, you *should* have got an exception) and go and
lookup the object again before continuing.

Regards,

  n