• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Pool and thread Ident/save Question

 
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Dan Bizman
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
reply
    Bookmark Topic Watch Topic
  • New Topic