Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.18.4, 2.19.0
-
None
-
Originally encountered with a JMS-Topic on a Software AG Universal Messaging Broker in Conjunction with Camel 2.18.2.
Reproduced on Glassfish 4.1.2 (to make sure the behaviour with the kept messages for suspended consumers is covered by the JMS reference implementation - and not depends on the broker implementation).Originally encountered with a JMS-Topic on a Software AG Universal Messaging Broker in Conjunction with Camel 2.18.2. Reproduced on Glassfish 4.1.2 (to make sure the behaviour with the kept messages for suspended consumers is covered by the JMS reference implementation - and not depends on the broker implementation).
-
Unknown
Description
Suspended JMS consumers only pausing the delivery of messages from the broker to the consumer. So if the suspended consumer gets active in case of a failover it receives all the messages the failed route has already processed - at least if it is connected via a non durable, non shared subscription to a JMS topic.
One might argue that this isn't a valid scenario - since you should involve queues (overhead of copying messages if a topic is what you really need) or shared durable subscriptions (only JMS >= 2.0; can lead to a (unwanted) backlog) if you use the ZooKeeper component for providing some kind of HA. One the other hand, if I need a lightweight solution and didn't care about the loss of some messages while the failover happens - and I absolutely need to avoid the additional load on the server for maintaining an additional queue because I rely on high throughput, I think I hit a scenario that isn't far-fetched.
Also I don't think it's good to have a unused active connection per slave-node to the JMS broker with respect to the usage of resources on the broker.
So my suggestion would be to solve this by really stopping the Consumer services. However I look at this issue by just inspecting the JMS behaviour - so maybe other consumer services exist that depend on the 'suspend'-behaviour (if the service isn't suspendable stop is called as a fallback anyway). So before talking about potential code changes I think we need to clarify if the described scenario is valid for camel-zookeeper and if stopping consumers is really the right solution for the issue.
Thanks in advance; and please let me know if something is unclear or if there are areas where I can provide/collect further information.
Attachments
Issue Links
- is related to
-
CAMEL-11400 RoutePolicySupport - Should have separated suspend/resume vs start/stop consumer
- Resolved