Обработка сообщения с [закрытыми] приоритетами
Определение номера исходящего вызова выполняется с помощью приемника вещания, но для управления вызовами требуется разрешение в манифесте. После получения события внутри приемника вещания вы можете легко завершить вызов внутри метода onReceive.
4 ответа
Установите приоритет сообщения, когда Вы звоните, "отправляют (..)" на MessageProducer (QueueSender, и т.д.). Или, можно установить приоритет по умолчанию на MessageProducer от 0-9 (9, является самым высоким). Установка приоритета на самом сообщении не будет работать. Это переопределяется Производителем.
Uri корректен - уважают ли приоритет, конкретная реализация. Я полагаю, что OpenJMS обычно уважает приоритет out-of-the-box, но не гарантирует это.
Состояния Спецификации JMS: "JMS does not require that a provider strictly implement priority ordering of messages; however, it should do its best to deliver expedited messages ahead of normal messages."
Значение по умолчанию приоритетов сообщения поддержек стандарта JMS равняется 4, можно указать других). Я думаю, что необходимо установить это в производителе сообщения И в самом сообщении (существуют методы на обоих).
Я думаю, что ActiveMQ действительно поддерживает его.
Однако у многих брокер JMS есть приоритетная обработка, отключенная по умолчанию. Существует флаг, который Вы, возможно, должны изменить, что-то как "supportJMSPriority", где-нибудь в конфигурации брокера.
Кроме того, Camel Apache позволяет Вам записать свое собственное сообщение resequencers, таким образом, Вы могли реализовать любую форму приоритета, который Вы хотели бы.
Вы могли использовать больше чем одну тему. Даже с приоритетами, если Ваш процессор занят, обработав более низкое сообщение с приоритетом, он не остановится что его выполнение.
Если у Вас есть отдельные процессоры, высокоприоритетное сообщение может начать обрабатывать, как только оно может быть поставлено, не ожидая никакого другого сообщения, которое будет обработано.
Почему бы не рассматривать использование другого MDB для обработки другого типа сообщения явно. Приоритетные детали выше все еще применяются, далее больше Вы имели бы больше контроля над параллельной обработкой для каждого типа сообщения.
Для большинства ситуаций я предпочитаю 1 mdb или получателя сообщения на тип сообщения. Таким образом, если транзакция откатывает Вас, сразу знает, какой тип сообщения вызвал проблему
Karl