Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Strange behavior with fixed pool thread and executor

 
Kody Wright
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Thanks for your time!

Here are the two main classes involved:

The client



The server

 
Maxim Karvonen
Ranch Hand
Posts: 121
12
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kody Wright
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alright I'll be sure to give those ideas a try, thanks for the reply!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic