I was wonder if using an executor service to handle clientSockets after being accepted is efficient? You would have one runnable per connection then if you have thousands of connections then you would have 1000's of runnables.
An example would be like this :
If you need one Runnable per connection then it's as good as possible.
But do you need one Runnable per connection? Well, it depends on what's happening with those connections. If the connection have clients who are sitting there trying to decide whether to buy green or blue widgets then you could look at other solutions which don't have Runnable objects just sitting there waiting for the client to respond. On the other hand if the connections have clients which are uploading large data files then maybe that is the best solution. So (as usual) it depends. Most general-purpose solutions wouldn't do it the way you described.
when handling connections in four or five figure sums you better of with NIO, its selector and channels
reason: NIO abstracts OS-level stuff hence its way better performance on heavy workload
NIO offers features like your code only serves the clients with active actions and just let sit those with waiting on client response with as less resources as possible wich is recommended in an environment mostly depending on remote/client actions and serving them than idle a lot of threads for each connection wich can lead to an easy way of (D)DoS your service by using up available resources stuck on waiting for client response
Matt Wong wrote:with NIO, its selector and channels
I checked the selector out and it seems useful. If you have runnables and you use an executor service it won't necessarily use one thread per runnable. Correct me if I'm wrong.
EDIT: OK I looked at selector more carefully and figured it could be used with executor service. If all the sockets are kept in the selector, they would be processed in a runnable only when they are ready for any read/write/accept. The runnable would only be responsible for one processing. That's what it seems like anyway.
Just for example, your typical web server accepts a connection, processes a request from the client, then terminates the connection. It doesn't keep permanent connections for any of its clients.
Okay, that isn't strictly different than what you asked but it sounded to me like you were thinking of more permanent connections.
So look at whatever it is which serves text messages to your cell phone. When you send a text to somebody you can see when they receive the text and you can tell when they are typing a reply. So there's some kind of long-running connection between you and the server and the other person, but how that connection is maintained is unknown to me.
I didn't think about how web servers do it. That's cool to think about that I could potentially make a basic web server like that. For a web server, I am assuming that for example tomcat would be setup to accept socket connections and then handle it asynchronously somehow then close the socket.