When using WSO2 ESB to mediate messages you often meet JMS related stuff. This is because in order to achieve
1. Guaranteed Delivery
2. Stored and forward messaging
3. Delivery order guaranteed
4. Message throttling without message loosing
you generally use a JMS broker.
If you intend to achieve one or few of above using pure JMS, it is very easy to achieve message conversion (SOAP/REST to JMS and vice-versa) and the integration.
For your first POC follow my article at WSO2 Oxygen Tank titled
"Configuring WSO2 ESB with WSO2 Message Broker"
There when you listen for messages using a JMS proxy at WSO2 ESB,
1. Rate of incoming messages is higher than message consuming (in application level processing is slow or you have a service chain to go though before you write modified messages to the database using transactions).
2. You need more to process parallel like a pipeline to your services. So WSO2 ESB should listen to another message and get it to processing while one is on the way.
3. You do not care about the order of messages processed. They are independent with each other.
In such a scenario, you can tell WSO2 ESB to listen for messages (from queue/topic) using many listener threads. We call them JMS message consumers. Each thread will get messages and feed them to synapse for further processing.
In JMS listener proxy define following properties to achieve that
1. Guaranteed Delivery
2. Stored and forward messaging
3. Delivery order guaranteed
4. Message throttling without message loosing
you generally use a JMS broker.
If you intend to achieve one or few of above using pure JMS, it is very easy to achieve message conversion (SOAP/REST to JMS and vice-versa) and the integration.
For your first POC follow my article at WSO2 Oxygen Tank titled
"Configuring WSO2 ESB with WSO2 Message Broker"
There when you listen for messages using a JMS proxy at WSO2 ESB,
1. Rate of incoming messages is higher than message consuming (in application level processing is slow or you have a service chain to go though before you write modified messages to the database using transactions).
2. You need more to process parallel like a pipeline to your services. So WSO2 ESB should listen to another message and get it to processing while one is on the way.
3. You do not care about the order of messages processed. They are independent with each other.
In such a scenario, you can tell WSO2 ESB to listen for messages (from queue/topic) using many listener threads. We call them JMS message consumers. Each thread will get messages and feed them to synapse for further processing.
In JMS listener proxy define following properties to achieve that
<parameter locked="false" name="transport.jms.ConcurrentConsumers">50</parameter> <parameter locked="false" name="transport.jms.MaxConcurrentConsumers">50</parameter>
Hi Hasitha, My scenario is similar to this. I have 1000 messages (can be processed in parallel) coming in a batch and ESB will be publishing the reference to the actual messages into a Queue as a JMS sender. As a JMS receiver, ESB has to be process all these messages in parallel. If I implement the parameter you have mentioned, would it work? Also, is there any limit how many concurrent consumers can be run by WSO2? Much appreciate your response. Thanks.
ReplyDeleteIf you listen for messages using a JMS proxy at WSO2 ESB, above parameter will work. As far as I am aware there is no limit to this, but remember that you are starting this many number of JMS message consumers underneath.
ReplyDelete