[omniORB] 'Rebooting' server and pending connections

[Brecht Vermeulen]

Hi all,

I've done some simple experiments with a persistent server and a client
(and omniORB4, of 21 March, on a Linux, Debian 2.2 platform).
So, the server object has a fixed IOR which is used by the client.
The client does 2 calls with some time in between and in between the two
calls I restart the CORBA server (which of course listens on the same
port and has the same IOR).

Now the client gives on the second call a COMM_FAILURE.

(this because the TCP connection is closed by the server and the client
doesn't notice this and thinks this connection is still valid).

I've read the omniORB manual : 8.3 and 8.4 and indeed with the option
-ORBoutConScanPeriod at the client side, I can force the client to shut
down the connection (which is in fact not valid anymore) before the 2nd
call executes and then the client establishes a new connection and the
call works.

However, I read in 8.4 :
The client should distinguish between an orderly and an abnormal
connec-tion shutdown. When a client receives a closeConnection message
before the con-nection is closed, the condition is an orderly shutdown.
If the message is not re-ceived, the condition is an abnormal shutdown.
In an abnormal shutdown, the ORB should raise a COMM_FAILURE exception
whereas in an orderly shutdown, the ORB should not raise an exception
and should try to re-establish a new connec-tion transparently.

So, I now wrote a CTRL-C handler in the server which does a
orb->shutdown(false) in a waiting thread and then does a orb->destroy()
after the orb->run() in the main thread. Is this then also an orderly
shut down ? (should the server ORB send a closeConnection to the client
then ?)

The traceLevel 100 output of this is:

Initiating clean ORB shutdown...
omniORB: Preparing to shutdown ORB.
omniORB: Starting an ORB shutdown thread.
done
omniORB: ORB shutdown thread started.
omniORB: Destroying POA(RootPOA).
omniORB: Destroying POA(persistent).
omniORB: Deactivating all POA(persistent)'s objects.
omniORB: State root/persistent<Echoobject> (active) -> deactivating
omniORB: Waiting for requests to complete on POA(persistent).
omniORB: Requests on POA(persistent) completed.
omniORB: State root/persistent<Echoobject> (deactivating) ->
etherealising
omniORB: Etherealising POA(persistent)'s objects.
omniORB: Removing root/persistent<Echoobject> (etherealising) from
object table
omniORB: Destruction of POA(persistent) complete.
omniORB: Deactivating all POA(RootPOA)'s objects.
omniORB: Waiting for requests to complete on POA(RootPOA).
omniORB: Requests on POA(RootPOA) completed.
omniORB: Etherealising POA(RootPOA)'s objects.
omniORB: Stopping serving incoming endpoints.
omniORB: throw giopStream::CommFailure from
giopStream.cc:812(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: Server connection refcount = 1
omniORB: giopServer waits for completion of rendezvousers and workers
omniORB: Server connection refcount = 0
omniORB: Server close connection from giop:tcp:157.193.184.93:1113
omniORB: Destruction of POA(RootPOA) complete.
omniORB: Shutting-down all incoming endpoints.
omniORB: TCP endpoint shut down.
omniORB: Disable ObjRef(IDL:atlantis.rug.ac.be/examples/echo:1.0)
root/persistent<Echoobject>
omniORB: Object table entry root/persistent<Echoobject> (dead) deleted.
omniORB: 1 object reference present at ORB shutdown.
omniORB: ORB shutdown is complete.
Proper termination... next, the ORB will be destroyed.
omniORB: 0 remaining ropes deleted.
omniORB: AsyncInvoker: thread id = 1 has exited. Total threads = 3
omniORB: Scan for idle connections (1017064518,565360000)
omniORB: Scan for idle connections done (1017064518,565360000).
omniORB: AsyncInvoker: thread id = 2 has exited. Total threads = 2
omniORB: AsyncInvoker: thread id = 3 has exited. Total threads = 1
omniORB: AsyncInvoker: deleted.
omniORB: No more references to the ORB -- deleted.
omniORB: Final clean-up
omniORB: Deleted 6 nil object references and 0 other tracked objects.
omniORB: Final clean-up completed.C


By the way, Orbacus e.g. can even handle the first scenario (without the
ORB destroyed properly, just the server 'rebooted' with CTRL-C without
the CTRL-C handler). 

regards,
Brecht