Question regarding best practices for handling client connections to server

[Kody Wright]

I am developing a server to handle chat requests and facilitate communication between other clients. So far things have worked well for the most part, but there is one issue in particular that I can't seem to figure out. I know that thousands of small servers like this have been written before so there must be a best practice of some sort to deal with this issue...I can't just seem to find it!

I'm using a fixed thread pool to manage the client connection threads to my server. As long as the amount of connections stay below the thread pool limit things work fine. However as soon as one client more than the thread pool size tries to join and send a message, a null pointer exception is thrown. I finally tracked it down to why it's being thrown but can't think of how to get around it. Currently, every time a new client joins they are
added to a client list (a list of clientDevice objects). When a client sends a message, my server iterates through that list and prints out the message to each one. However, if the amount of clients in the list exceeds
the active threads in the pool, then my server tries to send a message to a thread that isn't active, thus causing the null pointer exception.

There are two possible solutions I've thought of so far:

1) Find a way to iterate through the active threads in the pool and remove the client list all together I like this idea better, but can't for the life of me find out how to do this (or if it's even possible)

2) Only allow clients to connect long as the amount of currently connected clients does not exceed the thread pool limit. I don't like this solution because it would negate one of the benefits of using a thread pool (the thread queue) and also it seems a little hack-ish to me

I debated between putting this in the Threads section of the forums but ultimately thought I belonged better here since I'm seeking a socket-related suggestion. If I made the wrong choice feel free to move this over to the appropriate section. : )

Can anyone help me out? Thanks for your time and thoughts. Also, I can put up some code examples tomorrow if needed.

[Marco Ehrentreich]

Hi,

without knowing more details about your project I think there are at least some alternatives to this approach.

1.) Use a framework like Netty or Apache MINA to do the hard work. These frameworks are designed and optimized to build really scalable network applications. Of course you'd have to learn how to use these frameworks.

2.) If there are many clients (> 1000 ?) it may be a better to solution to use NIO and some non-blocking design instead of your thread-per-client approach. This allows you to handle much more clients than there are threads available at the cost of latency for example. So you have to decide if this is an issue for you because most operating systems get in trouble if you need thousands of threads.

3.) It seems that you are doing a lot of low-level work regarding thread management etc. If you want to stick with your approach maybe something like an ExecutorService would be helpful to dispatch jobs/client requests to a pool of threads which is automatically handled for you by the executor. This is surely easier to use and more robust than doing this yourself.

But as I wrote it is hard to give good advices without know your application in detail. Hopefully some of the advices are helpful to you.

Marco