Как установить тайм-аут для 0MQ (ZeroMQ) в Java? - PullRequest
Новая
       6

Как установить тайм-аут для 0MQ (ZeroMQ) в Java?

0 голосов
/ 28 июня 2018

Мне нужно добавить тайм-аут для транзакции ответа / запроса, используя 0MQ. Как это обычно достигается? Я пытался использовать метод: 

socket.setReceiveTimeOut();

и 

socket.setSendTimeout();

но они, похоже, вызывают исключение нулевого указателя.

По сути, я хочу, чтобы приложение истекло через 10 секунд, если приложение, получающее запрос, недоступно.

Любая помощь приветствуется.

Спасибо!

Ответы [ 2 ]

0 голосов
/ 29 июня 2018

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

Следующее сработало для меня, когда я использовал библиотеку JeroMQ (нативная реализация ZMQ на Java). Я использовал это, чтобы помочь выполнять команды REQ-REP через ZMQ. 

ZMQ.Context context = ZMQ.context(1);
ZMQ.Socket sock = context.socket(ZMQ.REQ);
sock.setSendTimeOut(10000); // 10 second send timeout
sock.setReceiveTimeOut(10000); // 10 second receive timeout
if (sock.connect("tcp://127.0.0.1:1234")) {
    if (sock.send(/* insert data here */)) {
        /* Send was successful and did not time out. */
        byte[] replyBytes = null;
        replyBytes = sock.recv();
        if (null == replyBytes) {
            /* Receive timed out. */
        } else {
            /* Receive was successful. Do something with replyBytes. */
        }
    }
}
0 голосов
/ 29 июня 2018

Как обычно выполняется этот [тайм-аут для транзакции ответа / запроса]?

Мне грустно подтверждать, в родном API ZeroMQ ничего подобного нет. Принцип выполнения асинхронной доставки означает, что нет предела для доставки (в модели планирования с максимальными усилиями, или нет вообще).

Если вы новичок в ZeroMQ, вы можете быстро прочитать это 5-секундное чтение об основных концептуальных элементах в иерархии [ ZeroMQ менее чем за пять секунд ] Раздел .

Я хочу ... тайм-аут после 10 секунд , если ... получение запроса не ...

Может спроектировать использование .recv() -метода в предварительно протестированном / защищенном после .poll( 10000 ) -методе метода, чтобы сначала явно обнаружить присутствие любого сообщение о том, что оно действительно доставлено в ваш код приложения, прежде чем когда-либо делать (или нет) вызов фактического .recv() -метода только на ранее отредактированном POSACK-сообщении, чтобы быть готовым к локальному чтению, или может использовать немного больше «необработанный» подход, использующий обработчик с неблокирующей формой метода, с помощью вызова флага .recv( ZMQ_NOBLOCK ), чтобы не тратить миллисекунду «там», в случаях, когда «там» нет сообщений для чтения прямо сейчас из локального Context() -инженерного экземпляра и обработайте каждый из случаев соответственно в вашем коде.

Бонусное очко

Также имейте в виду, что использование шаблонного архетипа REQ/REP -Scalable не будет проще, так как существует обязательный двухсторонний танец (конечно, если не умышленно, искусственно) ZMQ_RELAXED), так что оба FSA-back-to-back-connected-FSA-s все равно должны будут ждать следующего «ожидаемого» удаленного события, прежде чем смогут получить возможность обрабатывать следующее локальное событие , Если вас интересуют подробности, можно найти множество постов о взаимных тупиках, которые невозможно избежать, которые можно избежать, что обязательно случится для REQ/REP, где мы только не знаем, когда это произойдет, но уверены, что это произойдет.

...