camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Krasser (JIRA)" <>
Subject [jira] Commented: (CAMEL-1037) Messages in Resequencer between 2 JMS queues get stuck
Date Tue, 09 Dec 2008 08:50:05 GMT


Martin Krasser commented on CAMEL-1037:


thanks for applying the patch. You are completly right that during the sending from activemq.queue:out
to mock:result the exchange order is messed up because I've configured 10 concurrent consumers.
This is needed to test concurrent access to the resequencers but doesn't make any sense for
sending re-ordered messages to the mock endpoint - sorry for messing that up. An alternative
is to register a second JMS component configured with only one consumer, then the messages
are kept in order (but this doesn't bring any better test because all related issues came
from interaction with the first JMS queue ({{activemq.queue:in}} in our example. So we should
leave it as you suggested).

Regarding {{getCollection}}: The way how it is used in {{Aggregator}} doesn't make sense to
me either (even before the patch). In my opinion, it does make sense to keep the {{getCollection}}
method but it shouldn't be used to determine the current batch size. For that a separate {{getBatchSize}}
method should be provided that operates on the private queue (buffer) of the batch processor.

> Messages in Resequencer between 2 JMS queues get stuck
> ------------------------------------------------------
>                 Key: CAMEL-1037
>                 URL:
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 1.5.0
>            Reporter: Jonathan Anstey
>            Assignee: William Tam
>             Fix For: 1.5.1, 2.0.0
>         Attachments: camel-1.x.patch, camel-2.0.patch
> Martin describes the issue as follows in CAMEL-1034:
> "The issue with the regular resequencer (the one that extends the BatchProcessor) remains
because the process(Exchange) method is empty. In addition to the BatchProcessor's polling
consumer, an additional JmsConsumer is created by the JMS endpoint that competes with the
polling consumer. The JmsConsumer then calls the empty process(Exchange) method and the exchange
is lost."

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message