camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Ländle (JIRA) <>
Subject [jira] [Created] (CAMEL-11399) ZooKeeperRoutePolicy only suspends and not stops JMSConsumer
Date Tue, 13 Jun 2017 06:56:01 GMT
Andreas Ländle created CAMEL-11399:

             Summary: ZooKeeperRoutePolicy only suspends and not stops JMSConsumer
                 Key: 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

View raw message