Here is a tricky one that I hope you can help me with.
I have a client-server setup and I want the client to request a service from the server and continue normal operation while the server carries-out the request. At some point in time the server will finish doing what it was asked to do and I would like it to notify the client so the client can display some sort of message.
The magic of RMI makes it easy to call a method on a server object and this is what I use to notify the server of my request. The server then creates a seperate thread to carry-out the work and returns so the client cotinues normal operation. My problem is: how do I notify the client once the worker thread has finished?
Going from client to server is easy as there is only one server. The other way is tricky as there are nany clients. Any ideas would be much appreciated.
Either the client has to poll the server (or a chared resource, like some messaging setup), or the client has to be able to register itself on the server (not sure how that would work). Offhand I'd go for the former, but the actual realisation would depend on what your setup is.
The traditional way to accomplish this task is by polling, as Tolls suggested. However, this way suffers from a few flaws when there is a large number of clients:
1. if a lot of clients hit the server asking "have you finished yet?" server performance can go down.
2. if the frequency of polling is reduced to lower the performance overhead on the server, clients may not know that the operation has finished soon enough.
Neither 1 and 2 are necessarily a problem, it really depends on your requirements.
If it does become a problem for you, you can check out other paradigms that have developed in recent years, e.g.: XMPP and PubSubHubbub. They both have open source implementations.
That same RMI magic makes it just as easy to return something to the client that called the server. If you want to create another thread in the server to do the actual work your problem boils down to how to pass a value from one thread to a calling thread. Doug Lea wrote the wonderful java.util.concurrent package that can solve those problems. Have a look at the Future interface and the FutureTask class.
Originally Posted by zzpprk
Ok. I'll admit it. My undersrtanding of RMI is fairly limited.
Originally Posted by JosAH
I know about the interface (common to client and server), a stub class on the client and an implementing class on the server. When a claa a method on the stub, the request gets forwarded to the server object and the stub waits for that request to complete before returning. Fair enough!
My problem is that the stub has already returned because all the server did as a response to my request was to create a new thread and let it loose. The client is not waiting for the server to return anything.
In addition, there may well be several clients attached to the same server so how do I know which one to notify. Surely I need to pass something to the server so it can identify the correct client.