• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Multi-thread client-server / ObjectInputStream

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
reply
    Bookmark Topic Watch Topic
  • New Topic