Два потребителя на една и съща Websphere MQ JMS опашка, и двамата получават едно и също съобщение

Работя с някой, който се опитва да постигне поведение при балансиране на натоварването, използвайки JMS опашки с IBM Websphere MQ. Като такива, те имат множество потребители на Camel JMS, конфигурирани да четат от една и съща опашка. Въпреки че това поведение е недефинирано според спецификацията на JMS (последния път, когато погледнах все пак), те очакват нещо като кръгово поведение / поведение при балансиране на натоварването. И докато спецификацията оставя това недефинирано, аз съм накаран да вярвам, че нормалното поведение на Websphere MQ е да достави съобщението само до един от потребителите и че може да извърши някакъв вид натоварване - балансиране. Вижте тук например: Когато много MessageConsumer се свързва към същата опашка (Websphere MQ), как да заредя балансиран потребител на съобщения?

Но в този конкретен случай изглежда, че и двамата потребители получават едно и също съобщение.

Може ли някой, който е по-голям експерт с Websphere MQ, да хвърли някаква светлина върху това? Има ли ситуация, при която се очаква това поведение? Има ли промяна в конфигурацията, която може да облекчи това?

Склонен съм да кажа на всички тук да използват естественото съоръжение за клъстериране на Websphere MQ и да се откажат от наличието на множество потребители, сочещи към една и съща опашка, но това ще бъде голяма промяна за тях, така че бих искал да открия начин да направя тази работа.

Не че съм фен на разчитането на нещо недефинирано, но ако те желаят да разчитат на конкретното поведение на IBM, ще оставя това на тях.


load-balancing ibm-mq jms messaging mq
person mindcrime    schedule 17.04.2013    source източник

Отговори (1)


arrow_upward
3
arrow_downward

Единственият начин и двамата да получават едни и същи съобщения е:

  1. Има множество копия на съобщението.
  2. Приложенията преглеждат съобщението без заключване, след което се връщат обратно, за да го изтрият.
  3. Приложенията се отказват от транзакция и правят съобщението достъпно отново.
  4. Връзката се прекъсва, преди приложението да потвърди съобщението.

Препоръчителна практика е да се състезават няколко приложения за съобщения в опашка. Ако едно приложение не работи, опашката все още се обслужва. В клъстер това е от решаващо значение, тъй като клъстерът ще продължи да насочва съобщения към екземпляра на необслужваната опашка, докато не се запълни.

Ако това е система за разработка, инсталирайте SupportPac MA0W и му кажете да проследи само тази една опашка и ще можете да видите точно какво се случва.

Вижте спецификацията на JMS в раздел 4.4. Доставчикът никога не трябва да доставя второ копие на потвърдено съобщение. Изключение се прави за обработката на сесии в 4.4.13, което разглеждам в #4 по-горе. Това е доста недвусмислено и е част от официалната спецификация, така че не е специфично за IBM поведение.

person T.Rob    schedule 17.04.2013
comment
Благодаря T.Rob. Не съм разглеждал действителните спецификации от години, но си мислех, че когато има множество потребители на опашка (за разлика от тема), поведението е напълно недефинирано. Но може би това, че никога не се доставя второ копие на разпоредба за потвърдено съобщение, надделява над това. - person mindcrime; 18.04.2013
comment
Редът за доставка между конкуриращи се потребители е недефиниран. Доставката на съобщенията също се влияе от настройките за QOS. Ако приложението посочи мързеливо потвърждение, тогава може да получи подвеждания. Но ако съобщението е на опашка и е потвърдено и не е върнато назад или по друг начин има изключение, получавате еднократна доставка. - person T.Rob; 18.04.2013