Служба RMI работает аналогично сокетам - PullRequest
0 голосов
/ 01 мая 2019

Итак, если у меня есть сервер сокетов, я могу принять каждый сокет и передать его исполнительному органу

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

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

Это позволяет моему серверу работать в моих потоках и не блокировать тот же поток. Поскольку у меня также есть ссылка на этот сокет ... называемый "conn", я также могу успешно возвращать сообщения.

Теперь у меня есть интерфейс RMI, который в основном позволяет мне вызывать методы туда и обратно.

например, если бы у меня был этот метод:

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



        return res;
    }

Возвращает сериализуемый объект. Меня беспокоит то, что когда вызывается это сообщение, я думаю, что оно будет вызвано в главном потоке сервера и, таким образом, заблокирует этот поток и замедлит параллелизм.

Я думаю, что решение состоит в том, чтобы каждый метод RMI также создавал задачу для исполнителя ... для ускорения выполнения всего ... эта проблема, однако, я вижу, в отличие от сокета, где у меня есть объект чтобы отправить информацию обратно, я не уверен, как бы я возвратил ответ от метода RMI, без необходимости каким-либо образом блокировать поток.

Имеет ли это смысл? По сути, я спрашиваю, как я могу работать параллельно с методами RMI, но при этом иметь возможность возвращать результаты!

Спасибо за помощь!

1 Ответ

1 голос
/ 01 мая 2019

Имеет ли это смысл?

Нет.Параллельные вызовы изначально поддерживаются.

См. эту страницу документации и найдите свойство с именем maxConnectionThreads.

Вы могли бы также проверить свои предположения, например, напечатав текущее имя потока в коде своего сервера и попытавшись выполнить параллельные вызовы и посмотреть, что произойдет.

...