JMS listeners in an enterprise application
In our enterprise application, we need to have our JMS listeners that are manageable from SMA due to operational considerations.
We saw a link from PDN that will enable us to utilize JMS listeners even in an enterprise application setup which would allow us to manage our configured JMS listeners on an enterprise application deployment in SMA: https://community.pega.com/support/support-articles/enabling-jms-listeners-enterprise-using-dss
We understand that when Pega PRPC is deployed as an Enterprise application, it is recommended to use JMS MDBs as listeners to JMS queues & messages. Hope you can clarify us on the following questions regarding that:
1) Why are JMS MDBs recommended for use in consuming JMS messages on Pega PRPC over JMS listeners?
2) What are the possible drawbacks shall we proceed to enabling JMS listeners on a Pega PRPC enterprise application deployment?
Accepted Solution
PEG
IN
- In a Web deployment, a Java thread is assigned to each listener for the life of that listener. This allows the message-based listeners to block on the input queue, waiting for messages. With the arrival of a message, the listener thread wakes up to process the request.
- In an enterprise deployment, long-running threads are not allowed. Therefore, blocking is not an option and these listeners poll an input queue. If there are no messages to process, control returns to the application server, effectively returning the Java thread to the application server. After a predefined wake-up interval, the listener is again triggered to process any incoming messages that have arrived.
Please refer https://pdn.pega.com/using-mq-and-jms-services-enterprise-application-deployment
https://community.pega.com/sites/default/files/help_v72/procomhelpmain.htm
Standard Chartered Bank
MY
Thanks for responding to my inquiry. I was able to read it beforehand and I agree that in enterprise application deployment, its great to use MDBs as it allows JMS consumers to not "hog" threads during idle time that can be used on other tasks essentially making it event-based leading to better scalability as well as delegating the thread management shebang to the application server.
What we are curious is if there are any other Pega platform-specific reasons for going with MDBs on JMS message listeners? I just want to cover all my bases and know any gotchas we may need to know as we had an operational constraint that requires us to use JMS listeners on our Pega application in an enterprise application deployment.