[
https://issues.apache.org/activemq/browse/CAMEL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Krasser reopened CAMEL-126:
----------------------------------
Gert,
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
[http://www.nabble.com/forum/ViewPost.jtp?post=19344150&framed=y&skin=22882].
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.
Regards,
Martin
> provide a synchronous dispatch to the stream based resequencer for easier
> transaction support
> ---------------------------------------------------------------------------------------------
>
> Key: CAMEL-126
> URL: https://issues.apache.org/activemq/browse/CAMEL-126
> 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-2.zip, 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.
