shashank created CAMEL-26884:
--------------------------------
Summary: camel-nats - the stop of a consumer or producer ends
early when the flush of the connection fails, and a consumer misses a pull
subscription made while it stops
Key: CAMEL-26884
URL: https://issues.apache.org/jira/browse/CAMEL-26884
Project: Camel
Issue Type: Bug
Components: camel-nats
Reporter: shashank
Assignee: shashank
Follow-up of CAMEL-26462 (a consumer that stops before its task subscribes),
two of the three gaps named in its review, and the same flush in the producer;
on main.
* *Flush on a disconnected or closed connection.* {{NatsConsumer.doStop}} first
flushes the connection ({{flushConnection=true}} by default). jnats {{flush}}
throws a {{TimeoutException}} when the connection is not connected (the server
is down or restarting), and {{doStop}} ends there: the dispatcher is not
unsubscribed or closed, the JetStream subscription is not ended, the executor
of the consumer is not shut down, and a connection the consumer created is not
closed. The consumer is then marked failed, so a later stop does not retry.
With a shared connection ({{connection}} option), the stopped route keeps its
subscription when the server comes back, and a restart of the route adds a
second one; a connection the consumer created keeps reconnecting, and its
dispatcher subscribes again when the server comes back.
* *A JetStream pull subscription made while the consumer stops.* The pull
subscribe runs on the task of the consumer. When the subscribe completes just
before the stop and the task stores the subscription after {{doStop}} looked
for it, the client subscription is never unsubscribed (the fetch loop does not
run, as the consumer is stopping), so the server keeps a pull subscriber on the
consumer. The window is narrow.
* *The producer.* {{NatsProducer.doStop}} flushes the connection it created
before it closes it; a failed flush skips the close, and the connection keeps
reconnecting.
Not covered here (left for later): a quick stop and start while the task of the
first run still subscribes, and the fields of a run that gave up (they need a
token per run of the consumer).
*Proposal*
The flush in {{doStop}} of the consumer and the producer is best effort (WARN,
then the stop goes on); after the pull subscribe, the task ends the
subscription itself when the consumer is stopping (with the interrupt of the
stop cleared for the unsubscribe, as jnats drops a message queued on an
interrupted thread).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
