Bug 856 - thread leak with gram CallbackHandler
: thread leak with gram CallbackHandler
Status: RESOLVED FIXED
: CoG jglobus
gram
: 0.9.13
: All All
: P2 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-03-26 16:31 by
Modified: 2005-12-05 16:47 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-03-26 16:31:14
When using the gram APIs, a BaseServer class/thread is created and started to
handle any callbacks. But, the way I'm using the cog library,
BaseServer.shutdown() is never called so this thread hangs around forever.

I'm not sure what the appropriate fix is. One thing I do know is that Gram
deactivation (where handler.shutdown() is called) isn't being performed the way
I'm using the java cog. I'm using the gram client in my own server that doesn't
ever stop running, so the deactivation is never called. Plus, each connection to
my server sends a new proxy so I'll have 1 (proxy,handler) entry in the
callbackHandlers cache for each connection made to my server. The server gets
100s or 1000s of connections over time and it's running out of threads and memory.

I glanced at the 1.1a code, and this problem seems to be in there as well.
------- Comment #1 From 2003-04-14 00:18:32 -------
We can add a call that returns a handler for a given proxy and then you would 
have to call shutdown() on it or we can add a deactivateHandler() call that 
will call shutdown() for you for a given proxy. 
------- Comment #2 From 2003-04-14 16:52:13 -------
I actually hacked up the CoG to add something similar to the
deactivateHandler()
you suggest. I ended up thinking it was too much of a hack. I instead have the
CoG use 1 handler per user. If a new proxy is presented for a user that is too
much newer than the existing one (I think I picked 2 hours), I shutdown the
handler with the old proxy, and created a new handler on the same port with the
new proxy. There are some problems with this approach, obviously.

I'm not sure how much longer this code will be used, but you might want to
consider refactoring the whole thing. My first thought (and I didn't think
about
it for very long) is to change things around so that a Gram is the main service
object that has a proxy associated with it (I think this is what Gregor argued
for way back when :-). In other words make it look more like a service oriented
architecture, with the Gram being the service. So, you'd do something like:

Gram gram = new Gram(url,proxy);
GramJob job = new GramJob();
//setup job
gram.submit(job);
job.addListener(this); // the gram object would actually do the listening
// yadda yadda
gram.shutdown(); // or maybe gram.disconnect()?

This changes things so listening is per-gram and exposes a required shutdown to
the user. I think it would also get rid of the static methods and variables in
the Gram class and the duplicate calls between the Gram and GramJob classes.
------- Comment #3 From 2003-04-15 20:25:00 -------
We can change the proxy-handler mapping to be proxy identity-handler mapping. 
That way, you would have 1 handler per user then per proxy instance. But then 
you still wouldn't be able to access the handlers.. so maybe a best option is 
to define deactivateHandler() call and change the mapping to be credential 
identity based.

Since the whole world is switching to the OGSI interfaces it's probably not 
worth changing the GRAM CoG API now. It soon will be obsolete.
------- Comment #4 From 2003-04-25 02:21:34 -------
Added Gram.deactivateCallbackHandler(GSSCredential) function. The credential-
handler mapping was unchanged.