This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
My question deals with properly using a fixed thread pool to manage the client connections to my server. I am in the process of writing a fairly simple Java chat server. It works for the most part, but as soon as the number of client connections exceeds my fixed pool thread limit things start behaving oddly.
For example, I created the fixed pool thread and set it to 2 connections. So long as only 2 clients connect everything works fine and dandy...but as soon as client 3 comes in then he is put on hold (like I expected)...however when client 2 sends a message he is disconnected (or placed into the thread pool queue, I can't tell) and client 3 now assumes his place. Client 1 is always working fine.
I intended for client 3 to be put on hold indefinitely until client 1 or client 2 disconnect...but apparently I am not understanding the fixed thread pool correctly. I currently have it set to where a clients thread will end once he sends "@STOP" to the server...this is the point where I would expect client 3 to gain access since client 2's thread is no longer being used. What exactly am I doing wrong?
however when client 2 sends a message he is disconnected (or placed into the thread pool queue, I can't tell) and client 3 now assumes his place.
I believe you have a bug somewhere in a code. Maybe in a Chat class or somewhere else. Your code throws unchecked exception (NullPointerException, IllegalArgumentException, etc...) inside a ClientDevice.run method. This exception is never caught and run method terminates.
Wrap all you run code in something like
You may also add a finaly block to that statement and output some information about client termination so you will be notified both of normal and errorneous exits.
I used Throwable in this case only to help debugging. Usually you should not do that (and even catching Exception is considered a bad practice). But in this place you really need to know ALL reasons by which a thread may be terminated. You do not use any other ways (Futures in particular) to be notified about that errors. So it will be fine.
Joined: Mar 06, 2011
Alright I'll be sure to give those ideas a try, thanks for the reply!
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Strange behavior with fixed pool thread and executor