This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Multi-thread client-server / ObjectInputStream

 
Xavier Fabreguettes
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am trying to develop a multi-threaded server that will get some customized objects from a client via ObjectInputstream, spawn a thread per connection, process the data, and then back another customised object to the client via the same connection.
Considering that a client can send several requests during the same session (but not together, just one request at a time), I would like your opinions on the best approach:
1) I treat each request as if it was independent i.e. on receiving the request, a new socket connection is started and a client handler thread is spawned on the server side to handle the request. Once the response is sent back to the client, the connection is closed and the server is ready to handle of subsequent requests from the same client as if they were coming from a different client. [note the processing done on the server-side is not client dependent]
2) Same thing but once the first response is sent back to the client, I keep the connection alive to service subsequent requests coming from the same client. This approach avoids the overhead of creating a new connection for each requests but I am wondering about the cost of looping on the server side to see if request objects are coming in.
I would prefer 2) but it really depends on the way I hadnle the InputObjecttream. Indeed, if thought about using an infinite loop and keep doing things like:
// **** surrounding try/catch
// ois is my instance of ObjectInputStream
while (true) {
Object o = null;
try {
o = ois.readObject();
} catch (IOException e) {
continue;
}
try {
MyRequest req = (MyRequest) o;
MyResponse res = ... ; // processing
oos.writeObject(res);
} catch (EOFException e) {
// do something
}
}
This approach would consume quite a lot of processing time because of the infinite loop on the readObject() method.
My questions are:
- despite this, is approach #2 still better than #1 in terms of performance (the time processing of the loop is overall less than the processing of opening a connection everytime)?
- is there a better way to wait for new requests from the same client for approach #2, without consuming too many CPU cycles? Is there something similar to the classic
while (in.readLine() != null) {
...
}
used with InputStreamReader?

Many thanks for your help,
Xavier
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How many simultanious clients should the server be able to handle?
 
Xavier Fabreguettes
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good question! I don't really know as it is for the SCJD assignment and the specs are not specific enough (BTW I posted this message here and not in the SCJD forum as only few people are using sockets instead of RMI). I suppose you don't expect a lot of clients, maybe 20 (wild guess!).
In fact, what I'm interested in would be general pros and cons about the 2 options and also any idea about how to maintain the connection alive if we want to (the code sample with the infinite loop is certainly far from efficient but I don't see other ways to do it).
Cheers,
Xavier
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic