camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Krasser (JIRA)" <>
Subject [jira] Reopened: (CAMEL-126) provide a synchronous dispatch to the stream based resequencer for easier transaction support
Date Sun, 28 Sep 2008 08:13:52 GMT


Martin Krasser reopened CAMEL-126:


thanks for applying the patch. I re-opened this issue because of a thread-safety problem introduced
with the latest changes: {{StreamResequencer.process(Exchange)}} used the non-thread-safe
{{ResequencerEngine}}. I changed this method to be empty (this consistent with {{BatchProcessor.process(Exchange)}})
so that exchanges are only polled from an endpoint and synchronously sent to a destination/processor
using a single polling thread. The corresponding patch is {{camel-core.patch-update-3}}. 

(A multi-threaded {{Processor}}-based implementation has been discussed in [].
Not sure yet when I can provide an additional patch for that but as soon as I have one I'll
open another related JIRA issue for it).

With {{camel-core.patch-update-3}} I also added support for a more fluent resequencer configuration.
For example instead of writing {{from(...).resequencer(...).stream(new StreamResequencerConfig(5000,
4000L))}} you can now alternatively write {{from(...).resequencer(...).stream().capacity(5000).timeout(4000L)}}.
I'll update the documentation in the Camel Wiki as soon as the patch is applied.


> provide a synchronous dispatch to the stream based resequencer for easier transaction
> ---------------------------------------------------------------------------------------------
>                 Key: CAMEL-126
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>            Reporter: James Strachan
>            Assignee: Gert Vanthienen
>             Fix For: 1.5.0
>         Attachments: camel-core.patch, camel-core.patch-update,,
camel-core.patch-update-3, resequencer-docu.txt
> Currently the ResequencerEngine uses a Queue for asynchronous delivery of the messages.
We might want to provide a Processor instead; so we could if we prefer use synchronous dispatch.

> e.g. to be able to use a single thread and JMS transaction on a single JMS session (to
avoid XA etc) to do 
> * consume messages
> * reorder
> * send them on to another destination
> * jms session.commit()
> As far as I understand it, the current async mechanism will make transactional re-sequencing
harder right?

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

View raw message