aspose file tools*
The moose likes Threads and Synchronization and the fly likes Pool and thread Ident/save Question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Pool and thread Ident/save Question" Watch "Pool and thread Ident/save Question" New topic
Author

Pool and thread Ident/save Question

Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
I built a Connection pool that schedules threads to receive connections as they open up. Currently I am saving the thread name, but I know this is not guaranteed to be unique and may be diff. across OS's as well. However, the only thing I can think to do is save the Thread ref itself. Is there anything wrong/bad about this? Will it make this unmanageable memory-wise? Is there a better solution?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Ummm, using the thread reference sounds good to me. The only downside I see is if it's possible some threads will complete/die before the connection opens up. Retaining the Thread reference might keep the Thread object around longer than it needs to be in this case - in a long-running program that spawns many new threads in its lifetime, this could cause a memory leak, as you keep accumulating dead Thread references. I suppose this means you must either (a) write your code so as to guarantee that once a thread is scheduled to receive a connection, that thread cannot terminate without either receiving the connection, or notfying the connection pool that the connection is no longer needed. Or (b) create some sort of reaper thread whose job is to look for connections whose threads are now dead, and either set the thread ref to null and restore the connection to your "ready" pool - or close the connection and let it (and the associated dead thread) be GC-ed.


"I'm not back." - Bill Harding, Twister
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
"b" I can do no problem, but how would I do "a"? I have no control over the code that creates the threads and asks for a connection.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, how does a Thread get a connection? By calling a getConnection() method somewhere? Isn't that getConnection() code under your control? I'm guessing maybe it invokes wait() on some appropriate monitor object. You would need to consider - is there any way out or this? The user might call the interrupt() method I suppose - your getConnection() can handle this, maybe by batching the InterruptedException and de-scheduling the thread for a connection, then re-throw the InterruptedException so that the calling code can handle it however they want.
It's also possible the user might invoke deprecated methods like stop() or resume(). Of course, anything that goes wrong after that is their fault really. But you might at least check the isAlive() method of a thread before you return a Connection to it. If the thread is already dead, de-schedule it and log a warning, since there's no apparent good reason for this to occur.
With careful coding you may be able to avoid needing a reaper thread - but it's not a bad idea to have one anyway as a back-up if you're not sure what weird things other coders might try to do with your code.
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Thanks! I'll try that out. Yes, I am doing that wait() and I actually already have it in a block checking for interrupted and if so, i do remove it and throw an exception. however, I wrap the InterruptedException into my own and throw that. Should I be throwing an interruptedexception outside my pooledconnection code? The problem is i abstracted the thread handling out of the pool manager, so it uses my ThreadQueueManager so if an interrupted is thrown, it would happen inside that, then bubble up to the pool manager, then I'd throw it out of there. Plus in my thread manager I differentiate between that and simple timeout and throw them as different exceptions so they can be correctly handled by the pool manager.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, I suppose it's OK to wrap the InterruptedException in another custom exception. Personally I'd prefer to use the plain InterruptedException - it's the expected behavior when you interrupt() a number of other methods (sleep() and wait(), so it seems appropriate here too, IMO. I might have custom exceptions for other special situations, like a TimeoutException maybe, but I'd use InterruptedException when interrupt()-ed unless there's a need to provide more data in the exception than can be comfortably fit into InterruptedException. It's not too big a deal though - more important is that whatever the behavior is, it should be documented in the API so user know what to expect.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Pool and thread Ident/save Question