Suppose I have an RMI Client-Server application. Clients connect to the Server and at some point the Server starts a task. During the task Clients are doing some work, but at some other moment the Server must interrupt this work without letting the Clients finish it. Clients are implemented as Threads and the simplest solution looks like calling thread.interrupt(), but this does not work in RMI. Is there any other method or some workaround to resolve this problem? Thanks in advance.
You can implement a two-way remoting scheme in which, when a client performs the lookup for the server remote object and creates the local instance, it calls a method by which it passes a remote object of its own to the server. Then, when the server has finished its task, it can notify the client by calling a method in the remote object received from the client.
Related
I'm developing a standard java RMI server with multiple clients. These clients have a menu where they can call the server to do various of things for them.
One method involves a queue, where they can send a job to the queue and wait for it to get handled. The RMI server dispose threads for all the clients automatic, but when it comes to this method and queue, how can I hold this request back, so for example:
client 1 call first, and then client 2 calls just after (here client 1 should receive the message first from the server and client 2 should wait the time it takes for the server to process client 1 request)
Is it to make some kind of singleton only for this task?
What can I do to tackle this problem.
Make the remote method concerned synchronized.
No queue required.
I am following the Java RMI tutorial from here to build an example compute engine where the clients can submit tasks to a known server, and which the server will perform the task and return the result.
Having compiled and created new tasks sucessfully I want to learn further by reversing the logic, i.e. the server sends the task to the clients.
How would I conceptually do this? If I have understood correctly, the RMI server exposes the executeTask() method, which a client calls upon connecting to the server. I am toiling with turning each client into a 'server', each running an RMI registry and another application will connect to each of the rmi registries and call the executeTask method, and thus download the class.
Is there an obvious apporach in the logic I am missing? Having multiple RMI registries seem's incorrect.
What I want to end up with is a server with exposed RMI registry. All clients connect to server, server calls executeTask() method on each client to process the task on the clients. Ofcourse the task class needs to be located at the server and downloaded dynamically to the clients (currently the task is located at the client and sent to the server).
Have the server expose a fetchNextTask() method, and have the clients call it when they're ready to perform another task.
I am looking to build an instant messenger in Java.
Clients will connect to the server to log in.
They will start a conversation with one or more other clients.
They will then post messages to the server that will relay the messages to all the clients.
The client needs to be continually updated when users post messages or log in.
so the way I see it, the client needs to run a server itself in a separate thread so that the main server can send stuff to it. Otherwise the client will have to the poll the main server every xyz seconds to get the latest updates. And that would need a separate thread anayway, as that would be purely for getting updates whereas the 'main' thread would be used for when the client initiates actions such as posting messages/inviting others to conversations etc...
So anyone recommendations on how to write this instant messenger? Does it sound like a good idea to make the connection a 'two-way' connection where both the client and server act as servers? Or is polling a better option? Anyone know how the IRC protocol does this?
There's no real advantage of having 2 connections unless they can be handled independently (for example receiving / sending a file usually done in a separate connection). A connection itself is already a two-way communication channel so it can be used to both send and receive messages, events etc. You don't need to poll server since client is able to maintain persistent connection and just wait for data to appear (optionally sending periodic PING-like message to ensure connection is alive).
IRC uses a single connection to server to exchange text commands. For example one of the main commands:
PRIVMSG <msgtarget> <message>
This command can be originated either by client or by server. Client sends PRIVMSG to notify that it wants to deliver message to one or more destination (in IRC this either user(s) or channel(s)). Server's task here is to properly broadcast this message to appropriate clients.
If you're using raw InputOutput streams then yes this is a good way of doing it. You create one thread on the clientside that acts in a similar fashion as the server thread - waits for any incoming updates and when it does it updates the client. I wouldn't call it a server though. So you'd ideally have 2 TCP/UDP connections one for requests made by the client and one to notify the client of server changes.
This solution in an enterprise environment would probably be done through some kind of messaging framework such as Spring Integration but dig deep enough and it will essentially be a similar way to how you mentioned.
Do you need a fully custom protocol or would it be sufficient to use the XMPP? There are several open source libraries implementing XMPP.
http://xmpp.org/xmpp-software/libraries/
e.g. http://www.igniterealtime.org/projects/smack/
For me, to develop instant messaging service, I will use websocket protocol instead of normal java socket because the normal socket can not work well with HTTP protocol and moreover some network providers and firewalls banned custom ports. If you develop it in normal socket, your service could not be accessed by web clients.
Did you plan to develop the instant messaging service yourself? How about using other protocols such as Jabber?
I have developed an RMI application where the RMI server has to be started several times and also has to stop several times.
How can I stop the RMI server without closing the application?
How do I send notifications to all clients that the server is going to stop?
I'm not sure what you mean with the "RMI server", the RMI registry you cannot stop programmatically. But you can stop your service (bound to the RMI registry). You should invoke a custom method to cleanly shutdown your service and then unbindit from the registry.
Before this shutdown and unbinding you should inform all connected clients that the service will be shut down. This notification can be done by callback. Searching for RMI callback will give you a lot of examples and tutorials.
You don't really need to send a notification. Clients of an unexported remote object will get a NoSuchObjectEzception next time they do a remote method invocation on it. They just need to recognize the situation.
i have two clients in two different processes that communicate through RMI with the server.
my question is:
what happends if both clients invoking the server's stub at the same time?
thanks for you time,
me
This tutorial demonstrates the threaded nature of RMI servers (see task 7.1). They quote from the RMI spec:
A method dispatched by the RMI runtime
to a remote object implementation (a
server) may or may not execute in a
separate thread. Calls originating
from different clients Virtual
Machines will execute in different
threads. From the same client machine
it is not guaranteed that each method
will run in a separate thread
so invocations from different clients will result in execution via different threads in the server.
Nothing untoward by default - it's exactly the same as invoking a method on any other object from two threads simultaneously. The 1 server to many clients model is what network protocols like RMI are for.
Access to any shared data within the server needs to be regulated by synchronized blocks if need be. It depends what the server is doing.