[
https://issues.apache.org/jira/browse/CAMEL-11399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047537#comment-16047537
]
Claus Ibsen commented on CAMEL-11399:
-------------------------------------
Use the zookeeper-master component for this kind
> 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.18.4, 2.19.0
> 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)
