camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Resolved] (CAMEL-11399) ZooKeeperRoutePolicy only suspends and not stops JMSConsumer
Date Tue, 13 Jun 2017 15:38:00 GMT


Claus Ibsen resolved CAMEL-11399.
    Resolution: Fixed

> ZooKeeperRoutePolicy only suspends and not stops JMSConsumer
> ------------------------------------------------------------
>                 Key: CAMEL-11399
>                 URL:
>             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
>            Assignee: Claus Ibsen
>             Fix For: 2.20.0
> 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