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.
Related
I have a client server structure. The server exposes a service with RMI, let's say it is: RemoteInterfaceA. The service is regualary exported using UnicastRemoteObject.exportObject(service, port) and bound in the RMI Registry.
The server however must update something in the client so also the client creates a RemoteInterfaceB, it exports it using UnicastRemoteObject.exportObject(update, port). It cannot however create a Registry (because unlike the server it is not reachable from the internet). To give to the server its update stub, I pass the update as an argument of a service (RemoteInterfaceA) method.
Will it work?
It will work, firewalls permitting. As you say the client isn't reachable from the Internet, it won't for you. The server will get a NetworkUnreachableException or a connect timeout when it tries to callback the client.
I'm currently creating a Java Web Application that will use Websockets. The server would be a Java class annotated with #ServerEndpoint called Server.java and the client would be a web browser so I'll most definitely access the Websocket endpoint using Javascript.
I need a Websocket because I want to notify the client(s) whenever something in the server changes. We have a utility class called the EventManager that manages all the events that happen in a subsystem. I plan to register Server.java as a dependent of EventManager so that whenever EventManager has something new, it will notify all of its dependents that this particular event happened.
Is this good practice? I thought about using AJAX/long polling but I believe to server-to-client behavior needs to be observed. And besides, there's no way for me to get the events in the database, I have to rely on the EventManager to notify my Websocket endpoint.
Example scenario that I want:
Client A connects to Server.java
Client B connects to Server.java (by now, there will be two sessions active)
EventManager detects an event and notifies all instances of Server.java.
Server.java sends a message to all active Websocket sessions.
Browser retrieves data sent through Websocket using Javascript and displays it.
I have been told to use Node.js for this but I am still pushing for a Java implementation since:
I have completely no experience with Node.js
Our EventManager class will be such a pain to convert into
Javascript for Node.js
It will work the way you propose. A few pointers:
Remove zombie Servers (Server.java) from your event manager.
This will work fine with a single server machine, what happens with more? Client A and Client B may connect to different http processes.
When a client refreshes a page you lose the connection
You can use the fact that the ServerEndpoint can receive query params to pass state.
Connections drop. Remember to implement a keep alive.
You can only have one message encoder/decoder per websocket. Makes sense but requires a few ifs in the #OnMessage method.
Here is a sample implementation of a chat server with multiple servers using websockets.
I'm going to create an authentication server which itself interacts with
a set of different Oauth2.0 servers.
Netty seems to be a good candidate to implement network part here.
But before start I need to clear some details about netty as I'm new to it.
The routine will be as follows:
The server accepts an HTTPS connection from a client.
Then, not closing this first connection, it makes another connection
via HTTPS to a remote Oauth2.0 server and gets data
After all, the server sends the result back to the client which is supposed to keep the connection alive.
How to implement this scenario with Netty?
Do I have to create a new netty client and/or reconnect it each time I need to connect to a remote Oauth2.0 server?
If so, I'll have to create a separate thread for every
outgoing connection which will drastically reduce performance.
Another scenario is to create a sufficient number of Netty clients
within a server at the beginning (when server starts)
and keep them constantly connected to the Oauth2.0 servers via HTTPS.
That's easily done with Netty. First you set up your Netty server using the ServerBootstrap and then in a ChannelHandler that handles your connection from the client you can use e.g. the client Bootstrap to connect to the OAuth server and fetch the data. You don't need to worry about creating threads or similar. You can do it all in a non-blocking fashion. Take a look at and try to understand how this example works:
https://github.com/netty/netty/blob/master/example/src/main/java/io/netty/example/proxy/HexDumpProxyFrontendHandler.java#L44.
I'm really new to Java RMI, and I don't quite understand what it actually does. When a remote method is called, is the method executed on the server, or the client? In other words does RMI utilize the servers resources or is it simply used for access to remote classes and methods which will run client side?
Java RMI (Remote Method Invocation) uses client side "stubs" to connect to server side implementation and the real work is done on the Server side.
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.