Andreas Ländle created CAMEL-11399:
--------------------------------------
Summary: ZooKeeperRoutePolicy only suspends and not stops
JMSConsumer
Key: CAMEL-11399
URL: https://issues.apache.org/jira/browse/CAMEL-11399
Project: Camel
Issue Type: Improvement
Components: camel-zookeeper
Affects Versions: 2.19.0, 2.18.4
Environment: 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).
Reporter: Andreas Ländle
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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
