ORB does not perform clean up after destroy() is called.

Question

hi,
the HelloClient example (POA model) which is provided in the Java IDL tutorials, does not perform clean up after the execution is complete.
i.e. i can still find the Socket descriptors in the file system under the path (/proc/p_id/fd). Do we need to explicitly destroy the sockets inorder to perform the required clean up??the OS i'm using is Linux.
if yes, then how do i do that.... the following are the steps to reproduce the problem:
1)start HelloServer
2)start HelloClient
3)check file count in /proc/process_id/fd before calling init.
4)invoke ORB.destroy() method.
5)check file count in /proc/process-id/fd after destroy completes.I have included Thread.sleep(25000) inorder to check the file count dynamically at each stage of execution.
Any help in this regard is welcome....!!
thanks in advance

Answer 1

Hello:
This reply may be long after the time that you need it ... but the problem
that you are experiencing sounds very much like a bug that was fixed in the J2SE 1.5.0_10 release.
It is bug 6354718 ....
In the evaluation section of that bug they note:
Yes. It's a known bug in ORB connection management. What's happening here is, the connectionCache that maintains both inbound and outbound connections does not reclaim connections, upon ORB destroy() call. There is a connection reclaim() logic in place, but does not kick in, until it reaches certain watermark levels. Since, a single client can have a multiple ORBs and thereby multiple outbound connections (in the reported case) , with each cache having exactly one connection which leaks up on ORB exit. This leak multiplies based on the number of ORBs and time period over which client stays live, up and running.
The solution is, to walk through the connection cache and close each connection,
no matter what the watermark levels are. This can be done at the corba transport manager close() call.
Note: In the above evaluation they tell you how to fix it yourself but I believe (I haven't tested it yet ....) that if you upgrade to JDK 1.5.0_10, you should find that it has been fixed for you.
I hope that I'm not steering you wrong, but that's my take on your situation.
John