Потребитель Disrupror повторно отправляет данные

Я хочу использовать дизраптор LMAX, но не уверен, что мой вариант использования подходит для него. В основном есть один-два производителя и n потребителей. Хитрость заключается в том, что когда потребитель получает событие и проверяет некоторые данные о нем, он должен повторно опубликовать данные, если он не может сразу их использовать (в основном это схема опроса). Я создаю кольцевой буфер с емкостью, которая, я не волнуюсь, слишком мала, но теперь мой вопрос: безопасно ли запрашивать новые последовательности и публиковать их из обработчика событий, или это может как-то нарушить функциональность? После небольшого теста я сделал это достаточно безопасным, но я не знаю, как это будет вести себя в моем конкретном случае. Меня беспокоит, что метод onEvent может быть вызван после того, как я запрошу последовательность, но до того, как я обновлю-> опубликую новый объект, и я действительно не знаю, как нарушитель обрабатывает эти случаи


person omu_negru    schedule 14.10.2013    source источник
comment
Я ожидаю, что вы не сможете использовать сообщение, пока оно не будет опубликовано. И вы не можете повторно использовать сообщение, пока оно не будет использовано. Ключевое предположение нарушителя - производитель и потребитель неблокируют.   -  person Peter Lawrey    schedule 14.10.2013
comment
так что в основном, если я получаю последовательность в потребителе A, а затем последовательность в потребителе B, но я публикую последовательность B перед последовательностью A, тогда она будет видна первой, даже если порядковый номер (длинный) выше, а последующие вызовы next ( ) в кольцевом буфере в конечном итоге вернет последовательность A?   -  person omu_negru    schedule 14.10.2013
comment
События отмечаются как видимые для подписчиков только после публикации всех предшествующих событий. то есть слот 15 помечается как видимый только после того, как 14 помечен как опубликованный.   -  person Sam Turtel Barker    schedule 16.10.2013


Ответы (1)


Один из способов сделать это (без повторной публикации EventHandler событий) - реализовать отдельную «повторную публикацию» Disruptor. Если потребительский поток обнаруживает, что он не может сразу принять событие, он записывает событие в этот буфер, и отдельные потоки затем передают эти сообщения обратно в основную очередь событий.

Это увеличит количество писателей в основной очереди, но это кажется неизбежным с учетом варианта использования. Еще одна потенциальная проблема с этим решением заключается в том, что повторно опубликованные события должны потребляться после любых новых сообщений, которые были добавлены в основную очередь перед повторной публикацией.

person Andrew Bissell    schedule 14.10.2013