My consumer is rapidly churning connections for each message received
I am using a Spring DMLC to consumer messages from a Solace PubSub+ queue. When I check in the event logs, my consumer is rapidly churning connections for each message received. How can I fix this?
Best Answer
-
The recommended cache level is CACHE_CONSUMER which means that the JMS connection, JMS session and JMS consumer are all reused each time a message is processed in the DMLC. In Solace, this means that the client stays connected and the same flow remains bound to the queue for each message received. This is the way that the Solace platform is intended to behave and will achieve the best performance.
Setting the cache level in Spring to CACHE_NONE means that no JMS resource will be cached/reused. In Solace, this means that a new client connection is created for every message received. Setting the cache level in Spring to CACHE_SESSION means that the JMS connection and JMS session is cached, but the DMLC will obtain a new JMS consumer for each message received. In Solace, each JMS consumer represents a flow to the endpoint. When the message is consumed and the JMS consumer resource is destroyed, the flow is unbound from the queue in Solace. Both of these lead to unnecessary churning of resources and they are not recommended when a high rate of traffic is expected.
7
Answers
-
The recommended cache level is CACHE_CONSUMER which means that the JMS connection, JMS session and JMS consumer are all reused each time a message is processed in the DMLC. In Solace, this means that the client stays connected and the same flow remains bound to the queue for each message received. This is the way that the Solace platform is intended to behave and will achieve the best performance.
Setting the cache level in Spring to CACHE_NONE means that no JMS resource will be cached/reused. In Solace, this means that a new client connection is created for every message received. Setting the cache level in Spring to CACHE_SESSION means that the JMS connection and JMS session is cached, but the DMLC will obtain a new JMS consumer for each message received. In Solace, each JMS consumer represents a flow to the endpoint. When the message is consumed and the JMS consumer resource is destroyed, the flow is unbound from the queue in Solace. Both of these lead to unnecessary churning of resources and they are not recommended when a high rate of traffic is expected.
7