RMI Service run similar to sockets

Question

So if I have a socket server, I can accept each socket and pass it to a executory

while(true){
            Socket conn = socketServ.accept();
            Runnable task = new Runnable() {
                @Override
                public void run() {
                    try{
                        server.executor(conn);
                    } catch(IOException e){

                    }
                }
            };
            exec1.execute(task);
        }

Doing this allows my server to run on my threads and does not block the same thread. Because I also have reference to that socket... called "conn" I can successfully return messages as well.

Now I have an RMI interface, which basically lets me call methods back and forth.

for example if I had this method:

public MusicServerResponseImpl CreatePlayerlist(String Name, UserObjectImpl uo) throws RemoteException {
        MusicServerResponseImpl res = new MusicServerResponseImpl();



        return res;
    }

Which returns a serializable object. My concern is when this message gets called, I think it is going to get called in the main thread of the server, and thus will block that thread and slow down parallelism.

What I think is the solution is to have every single RMI method also create a task for an executor.. to speed up the execution of everything...this issue I am seeing however is unlike the socket where I have an object to send information back to, I am unsure how I would return a response from the RMI method, without somehow having to block the thread.

Does that make sense? Basically I am asking how I can execute in parallel with RMI methods while still being able to return results!

Thanks for the help!

Answer 1

Does that make sense?

No. Concurrent calls are natively supported.

See this documentation page and look for the property named maxConnectionThreads.

You could also have tested your assumptions by, for example, printing the current thread name in your server code, and trying to execute concurrent calls and see what happens.