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)

Reply via email to