Closing Corba Connections on the client end

[Jace Fly]

Hi guys,

I am no expert in Corba (or network programming for that matter), so forgive
me if get something wrong.

I have this Corba client that runs inside a servlet. Since we're using IBM
Websphere App. Server, we use the ORB inside Websphere to connect an
OrbixWeb Server. This all works fine until we start getting stale Corba
connections on the client end ie. proxy objects that are no longer usable
after getting a Corba exception. As soon as a connection becomes stale, we
either remove the proxy object from our connection pool or discard the
connection pool and recreate a new one. I was under impression that the
Java Garbage Collector would clean up the dereferenced proxy objects or
connection pools and free up any resources (e.g. file descriptors) held by
those objects. However, the Java Garbage Collector will only run when the
application reaches a certain memory threshold. There is no way to
explicitly invoke the Garbage Collector. As such, these stale proxy objects
are still hanging around, holding onto resources like file descriptors.
Eventually we reach a point where the application runs out of resources
(other than memory) before the Garbage Collector has a chance to run. This
results in the application slowing down to a grinding halt.

With this mind, is there anyway to explicitly close a Corba Connection on
the client end? Furthermore, if the Garbage Collector does happen to run,
is there any guarantee that all resources (including file descriptors,
sockets etc) held by dereferenced objects are freed? Will disconnecting or
shutting down the client ORB free up the network connections held by the
stale proxy objects?

I know that Orbix has a propriety method called closeChannel that allows you
to explicitly close a connection. This is fine if we're running Orbix on
the client end, but unfortunately we're not. Is there anything similar in
standard Corba?

Any help or advice would be appreciated.

Regards,

Jace.

[Frank Lynch]

Hi Jace,
Comments in-line below.
Regards,
--Frank

Jace Fly wrote:

> Hi guys,
>
> I am no expert in Corba (or network programming for that matter), so forgive
> me if get something wrong.
>
> I have this Corba client that runs inside a servlet. Since we're using IBM
> Websphere App. Server, we use the ORB inside Websphere to connect an
> OrbixWeb Server. This all works fine until we start getting stale Corba
> connections on the client end ie. proxy objects that are no longer usable
> after getting a Corba exception. As soon as a connection becomes stale, we
> either remove the proxy object from our connection pool or discard the
> connection pool and recreate a new one. I was under impression that the
> Java Garbage Collector would clean up the dereferenced proxy objects or
> connection pools and free up any resources (e.g. file descriptors) held by
> those objects.

This is not necessarilly true, an orb does not have to close connections to a
server when the last proxy referring to objects in that server has been
released. For example Orbix 2000 for Java will not close its connections just
because the last proxy has been released. This behavior is very much orb
dependent.

> However, the Java Garbage Collector will only run when the
> application reaches a certain memory threshold. There is no way to
> explicitly invoke the Garbage Collector.

Actually you can explicitly invoke on the Java Garbage Collector, simply do the
following:
System.gc();

> With this mind, is there anyway to explicitly close a Corba Connection on
> the client end? Furthermore, if the Garbage Collector does happen to run,
> is there any guarantee that all resources (including file descriptors,
> sockets etc) held by dereferenced objects are freed? Will disconnecting or
> shutting down the client ORB free up the network connections held by the
> stale proxy objects?

Any decent ORB should give you either a way of explicitly closing a conneciton,
or it will monitor the number of connections in use and manage them for you
ensuring that you never run out of file descriptors. You should have a look at
your orb's documentation I'd expect that it *should* have something on this very
issue.

[Jace Fly]

> > However, the Java Garbage Collector will only run when the
> > application reaches a certain memory threshold. There is no way to
> > explicitly invoke the Garbage Collector.
>
> Actually you can explicitly invoke on the Java Garbage Collector, simply
do the
> following:
> System.gc();

From what I have read, callling System.gc() won't guarantee that the Garbage
Collector will run. It only hints to the JVM that garbage collection should
occur. Whether or not it does is up to how the vendor has decided to
implement the JVM.

[Jace Fly]

I have worked out that we getting a new instance of the ORB everytime we
create a new proxy object. This would explain the number of connections
still hanging around when the proxy objects are discarded. Using only one
instance of the orb might possibly fix the problem, however, what can we do
if the Orbix Daemon on the server side dies or is restarted?

Would that mean that the orb on the client end now has a stale connection to
an orbix daemon that is no longer around?

I have found that if the Orbix Daemon is restarted, proxy objects created
using the client orb will not work, ie. a Corba exception will result when
attempting to make any method invocations on the proxy object.

So my plan is to either:

(1) Create a thread that monitors the connection from the client orb to the
Orbix daemon. As soon as the Daemon is restarted, I would like to destroy
and replace the client orb with a new Orb isntance. I need a way to detect
if the daemon has been restarted, so my question is: Is there anyway to
tell if the client orb is referencing a dead daemon?

(2) As soon a connection is established to the remote server, close the
connection to the daemon. Is there any non-Orbix specific way to close a
connection to a daemon besides destroying the orb?

"Jace Fly" <Jace...@altavista.com> wrote in message
news:3cbc1b18$0$15476$afc3...@news.optusnet.com.au...

[Puneet Agarwal]

I am no expert at CORBA but I do believe that the concept of PERSISTENT
Object References generated by setting the POA policy to PERSISTENT works
across object lifecycles as long as the POA is reconstructed in the same
manner. If thats true then if the server dies it can simply be restarted and
the old object refs should work at the client end I guess.

However, I am a beginner at CORBA so I may be way off target here. :-)

HTH,
Puneet

"Jace Fly" <Jace...@altavista.com> wrote in message

news:3cbeaccb$0$9993$afc3...@news.optusnet.com.au...