Мне нужно реализовать систему честного ожидания, чтобы сообщения обрабатывались циклическим способом на основе значения некоторого заголовка сообщения для всех значений этого заголовка для сообщений, находящихся в настоящее время в очереди.
Сообщения в системе естественно сгруппированы по некоторому свойству, из которых существует много тысяч возможных значений, а набор значений для входящих в настоящее время сообщений изменяется со временем. Аналогами были бы сообщения с заголовком, который является миллисекундной частью времени, во время создания сообщения. Таким образом, заголовок будет иметь значение от 0 до 999, и будет некоторое распределение значения для всех сообщений, находящихся в настоящее время в очереди.
Мне нужно иметь возможность потреблять сообщения в таком порядке, чтобы никакое другое значение не было приоритетным по сравнению с любым другим. Если значения заголовков сообщений в очереди распределяются таким образом,
value | count
------|-------
A | 3
B | 3
C | 2
Тогда порядок потребления будет A,B,C,A,B,C,A,B.
Если сообщения с другим значением добавляются в очередь, они должны автоматически добавляться в циклическую последовательность.
Это подразумевает некоторое знание текущих сообщений в очереди, но не требует, чтобы знания были сохранены потребителем; у брокера могут быть механизмы для заказа доставки в некотором роде.
Допустимо, что существует некоторый порог, за которым начинается честная очередь. Это означает, что если порог равен 10, то приемлемо последовательно обрабатывать 10 сообщений с одинаковым значением, но обрабатываемое 11-м сообщение должно быть следующего значения в последовательности. Далее может быть одно и то же значение, если только сообщения с очередью имеют это значение.
Количество возможных значений, вероятно, исключает просто создание очереди для каждого и повторение очередей, хотя это еще не проверено.
Мы используем HornetQ, но если есть альтернативы, которые предоставляют эту семантику, я бы с удовольствием узнал.
Сообщения - это задания, а значения заголовка - идентификаторы пользователей. Что нужно искать, так это то, что в некоторых пределах никакие задания от какого-либо конкретного пользователя не будут чрезмерно задерживать работу у любого другого пользователя; Пользователь, производящий 1 миллион рабочих мест, не приводит к тому, что последующие задания от других пользователей будут ждать обработки этого миллиона рабочих заданий.
Потребители в очередях в HornetQ оцениваются в порядке создания, поэтому добавление выборочного потребителя в очередь не помешает любому пользователю, имеющему доступ ко всему, получать сообщения, соответствующие фильтру.
Группы JMS, похоже, не помогают, поскольку это связывает данную группу (пользователя?) с данным потребителем.
Потенциальное решение создает выборочных потребителей по теме, основанной на спросе (например: 10 последовательных сообщений от одного и того же пользователя), с чем-то, управляющим жизненным циклом всех выборочных потребителей, чтобы гарантировать, что catch-all не обрабатывает одно и то же сообщение, Хотя это возможно, похоже, имеет некоторые обременительные требования к синхронизации.