Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How simple can a Server be?

 
Martin Habicht
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
How simple can a Server be, as it gives up to 53 points?
I'm asking because so far I have a very simple Server and all he does is to create an instance of a RemoteData object (which extends UnicastRemoteObject and redirects every mehtod call to a single Data instance). Then it puts it on the RMI-registry. Done! Only one command line parameter: the file name. No GUI, no extras.
Do you think such a server would be sufficient?

I agree, that for a nicer design, I would rather put a ConnectionFactory on the RMI-Registry, which would give each client it's own instance of a RemoteData (Data would still be Singleton). This would also allow tracking of Client-ID's for lock() and unlock().

Do I need to make the Server multithreaded explicitely?
Does the Server needs to have multiple threads to be able to accept a new rmi call before a previous hasn't returned because it got blocked?

After writing this, I guess it have to!
So then I could eighter have a thread for each client or better just start a new thread each time a request comes in.

any thoughts?!? thanks in advance...
-Martin

 
kerry shih
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Couple of comments:
Remember that for local usage, you have to completely bypass RMI. UnicastRemoteObject's immediately export upon construction.
I think the general idea is to have only 1 Data instance. If you serve one to every client then your are initializing the whole service on each request. Plus it precludes you from having a centralized management for record locking, id tracking etc.
RemoteObjects and decendants of remote objects are threaded servers once exported. In other words the threading work is done for you. To try it, simply export a server and have multiple remote clients connect.
Hope this helps,
Kerry
 
Peter Crowley
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Martin Habicht:
How simple can a Server be, as it gives up to 53 points?

You just have to meet the requirements.
I'm asking because so far I have a very simple Server and all he does is to create an instance of a RemoteData object (which extends UnicastRemoteObject and redirects every mehtod call to a single Data instance). Then it puts it on the RMI-registry. Done! Only one command line parameter: the file name. No GUI, no extras.


I agree, that for a nicer design, I would rather put a ConnectionFactory on the RMI-Registry, which would give each client it's own instance of a RemoteData (Data would still be Singleton). This would also allow tracking of Client-ID's for lock() and unlock().

Yes, you need to explicitly worry about threading.

Each time client that connects to your server they will be given a thread to work on. (Multiple clients = multiple threads) And each time the client calls a method, they might be given a different thread. (thread != clientID) For the factory's connections this is not a problem because a client will only be given one thread at a time as long as your client is single threaded, which almost never happens with GUIs. Someone can help verify this, but one of two things happen:
1)Every time a java.awt.event.Event happens your client spawns a seperate thread to handle that event.
2) For every event, the "swing" thread (the thread responsible for doing screen refreshes) handles the event. (I can see problems with this thread being blocked while waiting on the server if this is the case.)
If your client spawns two threads on the client (example #1 above), both could call methods on your server and get two threads running on your server on the same connection object.
Connection factory or not, I say that you should worry about threading.


Please comment if you know for certain that the awt events happen on their own thread for each event or if they share a single thread.


-Peter Crowley
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Both AWT and Swing are strictly single-threaded, and 99% of both is thread-unsafe. For that reason it is customary to handle time-consuming tasks (such as booking a seat ) in a separate (worker) thread - keeps the GUI responsive.
- Peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic