GetQueueMessage is evil

Aktywność 'Get Queue Message' w Tibco BW jest wąskim gardłem i może powodować problemy wydajnościowe przy masowych przepływach. Przy każdym wywołaniu jest tworzona nowa sesja JMS i nowy konsument. Stworzenie pierwszego konsumenta JMS z selektorem na "zimnej" sesji jest bardzo kosztowne, zwłaszcza przy dużym obciążeniu kolejki - podłączonych wielu receiverach/instancjach komponentu i braku ograniczeń przepływów (MaxJobs > 1000).

Jak zrobić request-response bez 'Get Queue Message' i bez JMS Requestor-a? Dwa oddzielne procesy w modelu asynchronicznym.

A co z 'Wait for JMS Queue Message'? Ta aktywność tworzy anonimowe procesy (i startery) obsługiwane przez standardową pulę wątków silnika BW, więc trzeba być z nią ostrożnym. Ponadto startery odbierają komunikaty we wszystkich instancjach komponentów i mogą wczytać odpowiedź w komponencie, który nie wysłał skorelowanego z nim żądania - w takim wypadku odpowiedź zostanie zgubiona. Dlatego każda instancja komponentu powinna mieć oddzielną kolejkę do odbierania odpowiedzi lub każdy nadany komunikat powinien mieć dodatkowy identyfikator instancji komponentu używany potem w selektorze 'Wait for JMS Queue Message'. Aktywność w trybie Client Ack i Auto wykorzystuje tylko jedną sesję JMS, dlatego przy szeregowym przetwarzaniu wartość pola konfiguracyjnego Event Timeout powinna być odpowiednio duża. Pamięć też...