[
https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040103#comment-17040103
]
Connor McAuliffe commented on CAMEL-14590:
------------------------------------------
The problem we are seeing is that unsubscribe does more than just stop the
consumer, it deletes the subscription if that consumer is the last consumer. So
if for some reason a route stops (we were playing around with dynamically
starting and stopping a route) the subscription, and more importantly the
cursor, get removed. Then when the route starts again it creates a new
subscription, meaning that you either have to use the earliest subscription
position and reprocess every message in the topic or use latest and miss every
message that was sent between when the route was stopped and started. I think
the method unsubscribe is poorly named given its functionality and not
documented well but that's a pulsar issue.
I am working on making a PR to make this configurable via camel but if you
think it sounds like a misuse then I would be more than happy to just remove
the call to unsubscribe altogether.
> Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially
> deleting subscription
> ----------------------------------------------------------------------------------------------
>
> Key: CAMEL-14590
> URL: https://issues.apache.org/jira/browse/CAMEL-14590
> Project: Camel
> Issue Type: Bug
> Components: camel-pulsar
> Reporter: Connor McAuliffe
> Priority: Major
>
> In the PulsarUtils [stopConsumers
> method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java]
> all the consumers call unsubscribe(). This causes the subscription to be
> deleted if this call comes from the last consumer. I do not know if this is
> intentional behavior but it seems to be dangerous (and has caused some issues
> for us without realizing it). If this is intentional, can we make it
> configurable to avoid doing this? Or if it is not intentional can we just
> remove the call entirely?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
