Остаются ли выборочно снятые сообщения в порядке FIFO (MQ)? - PullRequest
4 голосов
/ 03 октября 2011

При использовании JMS & WebSphere MQ, если я использую селектор сообщений для выборочного удаления из очереди, и есть несколько сообщений с одинаковыми критериями выбора, гарантированно ли я удаляю из очереди первое сообщение, которое соответствует?очередь с сообщениями

  1. {color: pink, name: alice}
  2. {color: blue, name: bob}
  3. {color: red, name: charlie}
  4. {color: blue, name: doug}

если я выключаю с помощью селектора color='blue', гарантированно ли я снимаю с очереди {color: blue, name: bob}?Или есть шанс, что я мог бы получить {color: blue, name: doug} вместо этого, даже если он находится в глубине очереди?

Ответы [ 2 ]

3 голосов
/ 03 октября 2011

Пожалуйста, обратитесь к свойству RESCANINT различных реализаций WMQ Connection Factory. Из руководства:

Когда получатель сообщения в двухточечном домене использует сообщение селектор, чтобы выбрать, какие сообщения он хочет получить, WebSphere MQ JMS-клиент ищет в очереди WebSphere MQ подходящие сообщения в последовательность, определенная атрибутом MsgDeliverySequence очередь. Когда клиент находит подходящее сообщение и доставляет его потребитель, клиент возобновляет поиск следующего подходящего сообщения от его текущей позиции в очереди. Клиент продолжает поиск таким образом, пока очередь не достигнет конца очереди или пока интервал времени в миллисекундах, определяемый значением срок действия этого свойства истек. В каждом случае клиент возвращается к начало очереди для продолжения поиска и новый интервал времени начинается.

Идея состоит в том, что в очень занятой очереди с доставкой по приоритету некоторые сообщения с более высоким приоритетом могут отображаться в очереди выше, чем текущая позиция селектора. Теоретически, сообщение с более высоким приоритетом должно использоваться в первую очередь, но потребитель не увидит его, если не будет искать в голове очереди. Курсор сбрасывается на начало очереди либо по достижении конца, либо по достижении RESCANINT. Настройка RESCANINT позволяет настроить то, насколько быстро вы хотите, чтобы селектор находил эти сообщения с более высоким приоритетом.

RESCANINT не относится к доставке FIFO. Другой случай, когда это может произойти, - это если несколько потоков с перекрывающимися критериями выбора. В этом случае один поток может держать сообщение под блокировкой и затем освободить его. Хотя сообщение может быть пригодным для второго потока, если этот поток уже прошел эту позицию в очереди, ему нужно нажать на конец очереди или истечь RESCANINT, чтобы перезапустить курсор, чтобы найти сообщение.

Интервал повторного сканирования в миллисекундах и по умолчанию равен 5000. Любое положительное целочисленное значение принимается, хотя слишком низкое значение приведет к сбою, так как курсор постоянно сбрасывается, прежде чем какие-либо сообщения могут быть использованы.

На практике вы будете получать сообщения по порядку, если очередь FIFO, и у вас есть только один читатель в очереди, для которого подходят сообщения, независимо от того, какой параметр RESCANINT установлен. Если порядок сообщений должен строго сохраняться, существуют некоторые дополнительные соображения, как описано в Последовательный поиск сообщений . Они сводятся к сообщениям, имеющим только один путь от производителя к потребителю при рассмотрении каналов, точек синхронизации и т. Д.

2 голосов
/ 03 октября 2011

См. Главу " Порядок, в котором сообщения извлекаются из очереди " и следующее: " Получение определенного сообщения ".

Подведение итогов: единственный способ получить сообщение, игнорирующее порядок FIFO, - это извлечь конкретное сообщение по его идентификатору или идентификатору корреляции. Очередь также может быть настроена на доставку в порядке приоритета FIFO +, но это не вариант, который вы рассматриваете. Наконец, порядок сообщений усложняется, если сообщения группируются, но, опять же, это не ваш случай.

...