shashank created CAMEL-26604:
--------------------------------
Summary: camel-seda - multipleConsumers: a route that starts or
stops consuming from the queue stops the other routes that consume from it
Key: CAMEL-26604
URL: https://issues.apache.org/jira/browse/CAMEL-26604
Project: Camel
Issue Type: Bug
Components: camel-seda
Reporter: shashank
Assignee: shashank
Found with Fray (controlled concurrency testing for the JVM) while testing seda
routes that start and stop while messages are sent, then reproduced with plain
JUnit tests.
With {{multipleConsumers=true}}, {{SedaEndpoint}} multicasts each message to
the processors of all consumers of the queue, with a {{MulticastProcessor}}
whose outputs are {{consumer.getProcessor()}}, the routes of the consumers.
When a consumer starts or stops (a route is added, removed, started, stopped,
suspended or resumed), {{updateMulticastProcessor}} stops the multicast
processor and creates a new one, which is started on the next poll. Stopping
the multicast processor stops its outputs, that is the other routes that
consume from the queue, and starting the new one starts them again.
{code:java}
from("seda:x?multipleConsumers=true").routeId("A").process(slowStep).to("mock:a");
// while route A processes a message in slowStep, route B is added (or stopped):
from("seda:x?multipleConsumers=true").routeId("B").to("mock:b");
// the message of route A fails at its next step with RouteStoppingException
and is lost (mock:a gets nothing)
{code}
Effects:
* an exchange that one of the other routes is processing fails at its next step
with {{RouteStoppingException}}: the processors of its route are stopped, and
they stay stopped until the next message is polled from the queue;
* the processors lose the state that they reset when they stop, for example an
aggregator forgets its closed correlation keys, so a message for a closed key
is aggregated again;
* every start and stop of one subscriber stops and starts the processors of all
the other subscribers.
CAMEL-6374 made a stop of one route not stop the multicast for the others; this
is what is left of it.
Expected: a route that starts or stops consuming from the queue does not change
the other routes that consume from it.
Suggested fix: wrap the processor of each consumer, as an output of the
multicast processor, in a processor that does not start or stop it; each
consumer starts and stops its own processor.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)