Коллеги,

Прошу Вашей помощи в решении следующей проблемы:

Есть RMI-взаимодействие вида клиент-сервер. Клиентом выступает некая система заказчика, то есть код клиента поменять возможности нет.
К коду сервера имею доступ, могу поменять в нем практически все, в пределах разумного конечно.

Процесс обработки запроса на сервере занимает около 3-4 секунд. Если за это время связь с клиентом была потеряна, то это надо как-то отловить и выполнить откат изменений.
Вопрос состоит в том, как отловить то что клиент отвалился?

Реализация интерфейса Unreferenced не подходит - требуется определить дисконнект именно конкретного клиента.

Буду признателен за любую помощь.

Создавайте registry програмно и передавайте ему свою RMIServerSocketFactory и RMIClientSocketFactory. А в этих фабриках создавайте свои сокеты которые будут враперами поверх обычных сокетов и которые будут перехватывать ошибки сокетного соединения.

 Мы идем одинаковым путем... Однако этот путь как-то слабо пока проходим. Мне не удалось, имея сокет, возвращенный ServerSocket.accept(), уловить, что с другой стороны закрыли соединение. Никаких ошибок, сокет по-прежнему bound, connected, !closed, !inputShutdown, !outputShutdown. getSocketChannel возвращает null, отсюда тоже не подступишься.

В общем, если эту задачу решить - остальное расскажу.

А разве RMI клиент не получит соответствующее исключение вместо ответа сервера? И сервер при попытке отослать ответ не получит исключение? Смысл RMI вроде в том, чтобы не знать слова "сокет".

Это сообщение отредактировал(а) COVD - 29.9.2010, 20:08

Клиент получит исключение если отвалился сервер, но этот случай к задаче не относится. Если отвалился клиент, то сервер ничего не получает, отправляет данные фактически "в пустоту". Там ситуация похожа на то, что описал Skipy: соединение со всех сторон валидно, а клиента уже нет.

LSD,

Спасибо за идею - буду пробовать, по результатам отпишусь. Пока же вопрос еще открыт.

Это сообщение отредактировал(а) jk1 - 29.9.2010, 20:34

Они разве по UDP общаются? Если же по TCP, то проблема в том, что встроенный механизм проверки соединения в TCP имеет слишком большой период и обрыв соединения может обнаружиться естественным образом, т.е. в виде исключения, через час, например. Это на чтении. А при записи сразу. И как можно "в пустоту" отправить по TCP непонятно. 

Можно реализовывать таймаут на уровне приложения. Или другое архитектурное решение. Если возникает идея "оптимизировать" RMI, то может лучше его вовсе не применять.  

В этом я с Вами согласен. Если мне кто-то объяснит, почему так происходит я буду очень признателен. Насчет урезать TCP-таймаут это интересно, надо будет попробовать.

Я бы и не связался с ним никогда, WS и все дела. Но решение приняли "архитекторы" наверху и руки у меня в этом отношении связаны.

YESSSSSS!    Я это сделал!

Как говорится, если гора не идет к Магомету, то Магомет идет к горе.

Собственно, надо было пройти на шаг дальше. Я перекрыл сокеты, а надо было еще и OutputStream, который возвращает сокет. И в конце обработки запроса этому outputStream-у ставить обработчик ошибок, который будет срабатывать на все IOException, которые непременно возникнут при попытке писать ответ в закрытый сокет. 

В общем, описываю схему на словах и прикладываю код, так проще понять будет.

1. Делаем wrapper-ы - MyServerSocket, MySocket и MyOutputStream. MyServerSocket на accept возвращает MySocket, MySocket в качестве output stream-а возвращает MyOutputStream.

2. Делаем реестр MySocket-ов. Он static и thread-local. При получении inputStream-а MySocket кладет себя в этот реестр.

3. Создаем интерфейс обработчика ошибок MyOutputStreamErrorHandler. Реализуем его в сервере так, чтобы он содержал все необходимые для отката данные. Устанавливаем реализацию этого интерфейса в MyOutputStream через MySocket, полученный из реестра.

4. В MyOutputStreamErrorHandler перехватываем все IOException, обрабатываем их с помощью установленного обработчика, исключение пробрасываем дальше.

Всё. Проверял, если сделать запрос, а потом срубить JVM (thread.stop не поможет) до возврата ответа - обработчик ошибки отрабатывает.

Запуск примера: сначала MyServerImpl, потом MyClient. Запрос обрабатывается 5 секунд, в течение которых JVM клиента можно срубить.

P.S. Ну повышайте же мне репутацию немедленно сейчас же!   

P.P.S. jk1, за задачу спасибо! Получил большое удовольствие!

Добавлено @ 11:13

Сервер, разумеется, получит. Но он устроен так:

Серверный сокет обрабатывает подключения. Создает клиентский сокет и некий обработчик в виде Runnable. Этот обработчик отдается потоку из пула, имеющегося у RMI.

Обработчик разбирает входной поток, десериализует данные, понимает, какой метод какого объекта надо вызвать. Находит соответствующий объект у себя в реестре, вызывает метод. Получает результат. Всё, Ваш серверный код RMI отработал. Дальше производится сериализация данных для ответа и только тут начинается запись в OutputStream. Естественно, она вызывает ошибку, ибо сокет закрыт, а в пустоту TCP отправлять не умеет. Но до Вашего серверного кода она не доходит, да и не должна. Сервер не должен отрабатывать клиентские ошибки (а то, что клиент отвалился, это проблемы исключительно клиента), он должен выдавать результат. Если нужен надежный возврат ответа сервера - делайте подтверждение вторым вызовом с клиента, при отсутствии которого в течение определенного времени осуществляется автооткат. Не наш вариант, мы не можем менять клиента.

Это сообщение отредактировал(а) Skipy - 30.9.2010, 11:16

Присоединённый файл ( Кол-во скачиваний: 12 )
 rmi_disconnect.zip 6,13 Kb

Упс, забыл! Там надо еще policy-файл при запуске сервера указать, иначе ошибки будут.

-Djava.security.policy=rmitest.policy

Файл прикрепил.

Присоединённый файл ( Кол-во скачиваний: 8 )
 rmitest.policy 0,05 Kb

Skipy, 

Спасибо за решение, то что надо. +1.

Единственное, что там надо доделать - аккуратно удалять из реестра MySocket, когда произошел сбой. Обычно он удаляется по socket.close, но в этом случае не факт, что socket.close вызовется. В принципе, ничего страшного не произойдет, если не удалить - я-то по ссылке проверяю, что сокет не мой, и переписываю. Но чтобы не оставались висячие объекты, лучше сделать.

Skipy, +1

Я рассуждал с позиции "используем RMI, следовательно, забываем про существование сокетов" и пришел к простому (и наверняка известному) правилу, что клиентское приложение всегда должно иметь таймаут на сетевое чтение. Если используемое средство коммуникации (например, RMI) не имеет встроенного таймаута или его параметры не настраиваются, то таймаут надо реализовывать в приложении.

Да есть у него таймаут... Лучше бы не было...  Свойство sun.rmi.transport.tcp.readTimeout:



Красиво? Кстати, в коде, где этот таймаут выставляется сокету, комментарий - "может, оставить это для фабрики?". ТАк что в фабрике тоже можно выставить, может, что-то интересное и получится. Хотя все равно сокет надо протащить в обработчик, чтобы понять, закрыт он или нет.

Да, два часа - это пока стандартное значение. Выставить вручную в сокете - вроде не на всех системах работает ( по слухам  ) . Таймаут на уровне приложения - самое надежное.

Это сообщение отредактировал(а) COVD - 30.9.2010, 17:50