Reusing object references - omniORB connection management

[Hans Huebner]

Hello there,

I am currently faced with the problem that our application processes keep 
object references to CORBA objects in memory.  This requires that objects 
reuse the same object reference when the server process is restarted.  I 
figured out how to re-create an object using a key argument which is 
passed to the server skeleton.  Now the servers are fine, and the objects 
they serve can be restarted on the same object reference they used to 
have in their previous lifes.
(I'd like to have an enhancement here, though:  omniBroker implements a 
proprietary make_inet_object (or some such), which, given a host, port 
and key triple creates an object reference which can be used both to 
(re-)start a server and get a reference to an object from a descriptive 
name.  We'd need such a thing in omniORB2)

But what about the clients?  If a server process is restarted, the client 
object reference is invalidated because it is tied to an open connection, 
which is of course closed when the server restarts.  It is my 
understanding of CORBA that object references are not tied to a 
connection, so I would expect that the ORB handles the reconnection if a 
server restarts.

I have been tracing through the ORB a bit, and found out that actually the
client does not (can not?) recognize that the server is no longer
listening.  This is due to the fact that, the active socket is not
notified if the passive socket (on the server) is shut down.

According to the CORBA specification, the server of an GIOP connection
should send a CloseConnection message if it no longer wants to serve
requests on a connection, but it also states that certain protocols, like
TCP/IP, need additional handshake mechanisms to ensure that this last
message is received by the client before the connection is finally run
down. 

As the spec does not give advice how this handshake should be performed in
IIOP, I'd suggest that the server does not close a connection after it has
sent the CloseConnection message to the client, but rather continues
reading requests until it receives an error by ::recv().   This strategy 
has the drawback that the server ORB must stay alive until all clients 
have disconnected their connections, which may or may not be acceptable 
depending on the application and context.

In any case, omniORB does need a mechanism to orderly shut down a server 
ORB, and in the shutdown process, the CloseConnection message must be 
sent to all clients currently connected.  This is a prerequesite for 
transparent reconnections of clients, which in turn is a must-have in 
most real-world applications (in which crashing servers are common).

One of the big problems with implementing orderly ORB shutdown in 
omniORB2 is class omni:: with it's bunch of static data members.  It 
would be much better to use the Singleton pattern for omni::, and create 
a single ORB object with a destructor.  The destructor would be 
responsible for cleaning up client connections, freeing allocated memory 
and all this.  I'd suggest to use reference counted pointers to the 
omni:: instance, and to have the instance() method call the destructor if 
the reference count becomes zero.

As ORL seems to be willing to accept patches to omniORB2, but such a 
change would be a major structural modifications, I'm not sure whether I 
should take the challenge and do it myself.  It would be very interesting 
to know what kind of work ORL currently does wrt omniORB2, and what 
resources are allocated to the project.

Please let us know.  I'm really pro GPLed software, but I'd rather try to 
keep enhancements coordinated, especially if they involve major changes 
which would make merging different branches of development difficult or 
impossible.

Thanks - Hans

--
Hans Huebner, IRS Berlin GmbH                     Phone : +49-30-2096 2158
                                                  Fax   : +49-30-2096 2157
Hans.Huebner@Berlin.IRS.DE                        Mobile: +49-177-512 1024