You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "dirk.mahler" <di...@buschmais.com> on 2008/09/05 15:16:23 UTC
Reliable resequencing
Hi,
we integrated Camel 1.4 as JBI component into ServiceMix and tried to use
the stream resequencer to reconstruct the "natural" order of our messages.
The routing on ServiceMix (SMX) level is defined as follows:
SMX transactional JMS/JCA consumer -> Camel JBI Component -> SMX Bean SE
The Camel JBI Component is configured to provide resequencing the following
way (I left out some message body conversion stuff):
from("jbi:endpoint:...")
.resequencer(sequenceExpression)
.stream(config)
.to("jbi:endpoint:.../beanEndpoint");
Resequencing seems to work but according to some simple tests it cannot be
guaranteed that all messages will reach the final consumer (in our case the
bean endpoint) if there's a system failure: Camel acknowlegdes the message
exchange to the JMS Consumer but then holds the messages in a non-persistent
queue before delivering them to the SMX bean endpoint. We found an existing
JIRA issue (CAMEL-126, https://issues.apache.org/activemq/browse/CAMEL-126)
which at a first glance seems to address our concerns by thinking about
synchronous dispatching - would this solve our problem or is there already
another solution?
-----
Dirk Mahler
Senior Consultant
-----------------------------------------------------------------
buschmais GbR
Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
Telefon +49 (0) 351 3209 23-0
Fax +49 (0) 351 3209 23-29
Telefon +49 (0) 1577 198 295 0
E-Mail dirk.mahler@buschmais.com
Internet http://www.buschmais.de
-----------------------------------------------------------------
--
View this message in context: http://www.nabble.com/Reliable-resequencing-tp19331003s22882p19331003.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Reliable resequencing
Posted by James Strachan <ja...@gmail.com>.
BTW it might make things simpler for now to use the Camel JMS
component and the resequencer to consume multiple messages in a single
JMS transaction when resequencing to avoid transaction issues with
JBI. i.e. do the resequencing using Spring/Camel/JMS before the
messages are put on the JBI bus
2008/9/5 dirk.mahler <di...@buschmais.com>:
>
> Hi,
>
> we integrated Camel 1.4 as JBI component into ServiceMix and tried to use
> the stream resequencer to reconstruct the "natural" order of our messages.
>
> The routing on ServiceMix (SMX) level is defined as follows:
>
> SMX transactional JMS/JCA consumer -> Camel JBI Component -> SMX Bean SE
>
> The Camel JBI Component is configured to provide resequencing the following
> way (I left out some message body conversion stuff):
>
> from("jbi:endpoint:...")
> .resequencer(sequenceExpression)
> .stream(config)
> .to("jbi:endpoint:.../beanEndpoint");
>
> Resequencing seems to work but according to some simple tests it cannot be
> guaranteed that all messages will reach the final consumer (in our case the
> bean endpoint) if there's a system failure: Camel acknowlegdes the message
> exchange to the JMS Consumer but then holds the messages in a non-persistent
> queue before delivering them to the SMX bean endpoint. We found an existing
> JIRA issue (CAMEL-126, https://issues.apache.org/activemq/browse/CAMEL-126)
> which at a first glance seems to address our concerns by thinking about
> synchronous dispatching - would this solve our problem or is there already
> another solution?
>
>
>
> -----
> Dirk Mahler
> Senior Consultant
>
> -----------------------------------------------------------------
> buschmais GbR
> Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
> Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
> Telefon +49 (0) 351 3209 23-0
> Fax +49 (0) 351 3209 23-29
> Telefon +49 (0) 1577 198 295 0
> E-Mail dirk.mahler@buschmais.com
> Internet http://www.buschmais.de
> -----------------------------------------------------------------
> --
> View this message in context: http://www.nabble.com/Reliable-resequencing-tp19331003s22882p19331003.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: AW: Reliable resequencing
Posted by Martin Krasser <de...@martin-krasser.de>.
Hi Dirk,
sorry for the late reply. I opened a JIRA ticket for reliable resequencing
(https://issues.apache.org/activemq/browse/CAMEL-949). I'll try to address
your questions (how to handle delivery failures ... etc.) when working on a
patch. Did you make any progress in the meantime (ideas, patches ...)?
Cheers,
Martin
Dirk Mahler wrote:
>
> Hi Martin,
>
> sorry for the late response - lot's of work is waiting ;-) But
> nevertheless thanx for your answer even if it contains bad news for us...
>
> I'd like to give you some feedback on your ideas - please note that I do
> not know Camel and it's internal structures very well.
>
>
> Martin Krasser wrote:
>>
>> - Batch resequencer: read n messages within a single transaction (instead
>> of
>> n transactions as done currently in 1.4), reorder them, send them to a
>> destination and commit the transaction. This can easily done within a
>> single
>> thread.
>>
>
> Might work but I doubt that the batch sequencer makes sense in a real
> world because IMHO it fails on the borders between two batches. A short
> example: Imagine a batch size of 3 and an incoming message order
> 1|2|4|3|5|6. This would result in sequential processing of two batches.
> There is no need to do any re-ordering in any of these batches but
> messages 3 and 4 will finally be delivered in wrong order to the consumer.
>
>
> Martin Krasser wrote:
>>
>> - Stream resequencer: the situation is more tricky here because there is
>> a
>> continuous stream of messages without having candidates for transaction
>> boundaries (in contrast to the batch resequencer where the batch size can
>> be
>> used to determine a transaction boundary). I'm still not 100% sure how to
>> solve this problem but a possible solution might roughly look like this:
>> Read messages from a source endpoint with n threads, suspend them until
>> they
>> have been re-ordered based on the message they have read and
>> resume/execute
>> them sequentially after their message becomes eligible for delivery.
>> After
>> delivery of the message each thread commits the transaction it started.
>> Consequently, each message is delivered to a destination within a
>> separate
>> transaction (in contrast to the batch resequencer where several messages
>> can
>> be delivered within a single transaction) but the resequencing is
>> reliable
>> too.
>>
>
> What I understand seems to be similar to the thoughts I have in mind about
> how it could work. I'll try to explain in my own words:
>
> MessageExchanges are consumed by the resequencer in n threads. Each thread
> is stopped until the predecessor of this message exchange has been
> delivered to the final consumer or the configured timeout is over. In the
> first case the MessageExchange is sent in the same thread it came from to
> the consumer. After receiving the response from there this will be sent
> back to the originating message producer.
>
> Or shorter: this is just synchronous communication which is stopped (->
> messageExchange.wait(timeout)) - until a required precondition is met ->
> messageExchange.notify(). This way there should be no problem of
> propagating a transaction context or an error state.
>
> One further question: what should happen, if delivery of a MessageExchange
> to the final consumer fails - should all pending MessageExchanges be
> rejected or delivered? Maybe several strategies should be provided.
>
--
View this message in context: http://www.nabble.com/Reliable-resequencing-tp19331003s22882p19737595.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: AW: Reliable resequencing
Posted by Dirk Mahler <di...@buschmais.com>.
Hi Martin,
sorry for the late response - lot's of work is waiting ;-) But nevertheless
thanx for your answer even if it contains bad news for us...
I'd like to give you some feedback on your ideas - please note that I do not
know Camel and it's internal structures very well.
Martin Krasser wrote:
>
> - Batch resequencer: read n messages within a single transaction (instead
> of
> n transactions as done currently in 1.4), reorder them, send them to a
> destination and commit the transaction. This can easily done within a
> single
> thread.
>
Might work but I doubt that the batch sequencer makes sense in a real world
because IMHO it fails on the borders between two batches. A short example:
Imagine a batch size of 3 and an incoming message order 1|2|4|3|5|6. This
would result in sequential processing of two batches. There is no need to do
any re-ordering in any of these batches but messages 3 and 4 will finally be
delivered in wrong order to the consumer.
Martin Krasser wrote:
>
> - Stream resequencer: the situation is more tricky here because there is a
> continuous stream of messages without having candidates for transaction
> boundaries (in contrast to the batch resequencer where the batch size can
> be
> used to determine a transaction boundary). I'm still not 100% sure how to
> solve this problem but a possible solution might roughly look like this:
> Read messages from a source endpoint with n threads, suspend them until
> they
> have been re-ordered based on the message they have read and
> resume/execute
> them sequentially after their message becomes eligible for delivery. After
> delivery of the message each thread commits the transaction it started.
> Consequently, each message is delivered to a destination within a separate
> transaction (in contrast to the batch resequencer where several messages
> can
> be delivered within a single transaction) but the resequencing is reliable
> too.
>
What I understand seems to be similar to the thoughts I have in mind about
how it could work. I'll try to explain in my own words:
MessageExchanges are consumed by the resequencer in n threads. Each thread
is stopped until the predecessor of this message exchange has been delivered
to the final consumer or the configured timeout is over. In the first case
the MessageExchange is sent in the same thread it came from to the consumer.
After receiving the response from there this will be sent back to the
originating message producer.
Or shorter: this is just synchronous communication which is stopped (->
messageExchange.wait(timeout)) - until a required precondition is met ->
messageExchange.notify(). This way there should be no problem of propagating
a transaction context or an error state.
One further question: what should happen, if delivery of a MessageExchange
to the final consumer fails - should all pending MessageExchanges be
rejected or delivered? Maybe several strategies should be provided.
-----
Dirk Mahler
Senior Consultant
-----------------------------------------------------------------
buschmais GbR
Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
Telefon +49 (0) 351 3209 23-0
Fax +49 (0) 351 3209 23-29
Telefon +49 (0) 1577 198 295 0
E-Mail dirk.mahler@buschmais.com
Internet http://www.buschmais.de
-----------------------------------------------------------------
--
View this message in context: http://www.nabble.com/Reliable-resequencing-tp19331003s22882p19396212.html
Sent from the Camel - Users mailing list archive at Nabble.com.
AW: Reliable resequencing
Posted by Martin Krasser <de...@martin-krasser.de>.
Hi Dirk,
the short answer is: no, the latest patch contained CAMEL-126 doesn't solve
the problem that you might loose messages if there a system failure. The
long answer is: it is only a first step into that direction:
a) The patch ensures that reading a message from an endpoint and delivery of
pending/reordered messages occurs within a single thread (in Camel 1.4 there
is still a separate thread doing the delivery). However, the transaction
from the source endpoint currently isn't propagated yet.
b) The patch changes the current implementation of the stream resequencer to
work with a polling consumer in the same way as the batch resequencer does
(btw, the batch resequencer currently isn't suitable for reliable
resequencing as well, from what I can see from the source code).
To make both resequencers reliable the following extensions are required:
- Batch resequencer: read n messages within a single transaction (instead of
n transactions as done currently in 1.4), reorder them, send them to a
destination and commit the transaction. This can easily done within a single
thread.
- Stream resequencer: the situation is more tricky here because there is a
continuous stream of messages without having candidates for transaction
boundaries (in contrast to the batch resequencer where the batch size can be
used to determine a transaction boundary). I'm still not 100% sure how to
solve this problem but a possible solution might roughly look like this:
Read messages from a source endpoint with n threads, suspend them until they
have been re-ordered based on the message they have read and resume/execute
them sequentially after their message becomes eligible for delivery. After
delivery of the message each thread commits the transaction it started.
Consequently, each message is delivered to a destination within a separate
transaction (in contrast to the batch resequencer where several messages can
be delivered within a single transaction) but the resequencing is reliable
too.
So far I had no time to work on these extensions. The initial patch of
CAMEL-126 is planned to be applied with Camel 1.5, so I'll try to get the
extensions done in the 1.6-SNAPSHOT because I also see the need for reliable
stream resequencing in one of my upcoming projects.
Even if it's not an immediate help for your problem, do the proposed
extensions make sense to you? Can you see any alternatives how to solve the
reliable (stream) resequencing problem?
Cheers,
Martin
> -----Ursprüngliche Nachricht-----
> Von: dirk.mahler [mailto:dirk.mahler@buschmais.com]
> Gesendet: Freitag, 5. September 2008 15:16
> An: camel-user@activemq.apache.org
> Betreff: Reliable resequencing
>
>
> Hi,
>
> we integrated Camel 1.4 as JBI component into ServiceMix and tried to use
> the stream resequencer to reconstruct the "natural" order of our messages.
>
> The routing on ServiceMix (SMX) level is defined as follows:
>
> SMX transactional JMS/JCA consumer -> Camel JBI Component -> SMX Bean SE
>
> The Camel JBI Component is configured to provide resequencing the
> following
> way (I left out some message body conversion stuff):
>
> from("jbi:endpoint:...")
> .resequencer(sequenceExpression)
> .stream(config)
> .to("jbi:endpoint:.../beanEndpoint");
>
> Resequencing seems to work but according to some simple tests it cannot be
> guaranteed that all messages will reach the final consumer (in our case
> the
> bean endpoint) if there's a system failure: Camel acknowlegdes the message
> exchange to the JMS Consumer but then holds the messages in a non-
> persistent
> queue before delivering them to the SMX bean endpoint. We found an
> existing
> JIRA issue (CAMEL-126, https://issues.apache.org/activemq/browse/CAMEL-
> 126)
> which at a first glance seems to address our concerns by thinking about
> synchronous dispatching - would this solve our problem or is there already
> another solution?
>
>
>
> -----
> Dirk Mahler
> Senior Consultant
>
> -----------------------------------------------------------------
> buschmais GbR
> Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
> Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
> Telefon +49 (0) 351 3209 23-0
> Fax +49 (0) 351 3209 23-29
> Telefon +49 (0) 1577 198 295 0
> E-Mail dirk.mahler@buschmais.com
> Internet http://www.buschmais.de
> -----------------------------------------------------------------
> --
> View this message in context: http://www.nabble.com/Reliable-resequencing-
> tp19331003s22882p19331003.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
RE: Reliable resequencing
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
Did you every get a response to this one?
I will try to get some attention to the CAMEL-126 issue and with help from SMX people also.
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: dirk.mahler [mailto:dirk.mahler@buschmais.com]
Sent: 5. september 2008 15:16
To: camel-user@activemq.apache.org
Subject: Reliable resequencing
Hi,
we integrated Camel 1.4 as JBI component into ServiceMix and tried to use
the stream resequencer to reconstruct the "natural" order of our messages.
The routing on ServiceMix (SMX) level is defined as follows:
SMX transactional JMS/JCA consumer -> Camel JBI Component -> SMX Bean SE
The Camel JBI Component is configured to provide resequencing the following
way (I left out some message body conversion stuff):
from("jbi:endpoint:...")
.resequencer(sequenceExpression)
.stream(config)
.to("jbi:endpoint:.../beanEndpoint");
Resequencing seems to work but according to some simple tests it cannot be
guaranteed that all messages will reach the final consumer (in our case the
bean endpoint) if there's a system failure: Camel acknowlegdes the message
exchange to the JMS Consumer but then holds the messages in a non-persistent
queue before delivering them to the SMX bean endpoint. We found an existing
JIRA issue (CAMEL-126, https://issues.apache.org/activemq/browse/CAMEL-126)
which at a first glance seems to address our concerns by thinking about
synchronous dispatching - would this solve our problem or is there already
another solution?
-----
Dirk Mahler
Senior Consultant
-----------------------------------------------------------------
buschmais GbR
Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
Adresse buschmais GbR, Leipziger Straße 93, 01127 Dresden
Telefon +49 (0) 351 3209 23-0
Fax +49 (0) 351 3209 23-29
Telefon +49 (0) 1577 198 295 0
E-Mail dirk.mahler@buschmais.com
Internet http://www.buschmais.de
-----------------------------------------------------------------
--
View this message in context: http://www.nabble.com/Reliable-resequencing-tp19331003s22882p19331003.html
Sent from the Camel - Users mailing list archive at Nabble.com.