FAQ
Hi guys,

consider the following route:

from(srcEndpoint).
to(destEndpoint1).
to(destEndpoint2)

I have a Java program which does the following:
- create a Camel exchange, add an onComplition action to remove the exchange
from the cache on success, store the exchange in a cache, and then send it
to the srcEndpoint.
The camel route takes it from there and delivers the exchange to
destEndpoint1 and destEndpoint2.
If the JVM crashes between destEndpoint1 and destEndpoint2, then I make a
flush which:
- gets the Exchange from the cache and sends it to srcEndpoint.

My question is:
What is the Camel way to prevent destEndpoint1 from receiving the same
exchange twice (as it was already received before the JVM crash)? Please
note that there might be more then two destination endpoints in the route.
Is it possible to instruct the route not to deliver the message to endpoints
that have already received (acknowledged) it? Is this an exchange
configuration?

If there is no Camel feature that would do this for me, what is your
recommendation: where should I plug-in my custom logic to perform what's
necessary to avoid duplicate messages?

Best regards,
Atanas



--
View this message in context: http://camel.465427.n5.nabble.com/Avoiding-duplicate-messages-tp5746278.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Search Discussions

  • Richard Kettelerij at Jan 21, 2014 at 2:54 pm
    Your use case it slightly different then the standard use case but perhaps
    the Idempotent Consumer will suit your needs?
    http://camel.apache.org/idempotent-consumer.html

    On Tue, Jan 21, 2014 at 2:12 PM, shindito wrote:

    Hi guys,

    consider the following route:

    from(srcEndpoint).
    to(destEndpoint1).
    to(destEndpoint2)

    I have a Java program which does the following:
    - create a Camel exchange, add an onComplition action to remove the
    exchange
    from the cache on success, store the exchange in a cache, and then send it
    to the srcEndpoint.
    The camel route takes it from there and delivers the exchange to
    destEndpoint1 and destEndpoint2.
    If the JVM crashes between destEndpoint1 and destEndpoint2, then I make a
    flush which:
    - gets the Exchange from the cache and sends it to srcEndpoint.

    My question is:
    What is the Camel way to prevent destEndpoint1 from receiving the same
    exchange twice (as it was already received before the JVM crash)? Please
    note that there might be more then two destination endpoints in the route.
    Is it possible to instruct the route not to deliver the message to
    endpoints
    that have already received (acknowledged) it? Is this an exchange
    configuration?

    If there is no Camel feature that would do this for me, what is your
    recommendation: where should I plug-in my custom logic to perform what's
    necessary to avoid duplicate messages?

    Best regards,
    Atanas



    --
    View this message in context:
    http://camel.465427.n5.nabble.com/Avoiding-duplicate-messages-tp5746278.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Atanas Shindov at Jan 21, 2014 at 7:27 pm
    Hi Richard,

    thanks for your prompt reply.

    It looks like the Idempotent Consumer might help, especially if in it's
    File/JDBC based implementations the message ids are durably persisted (it
    seems quite logical to be so), so that they are available after a JVM
    restart for example.

    However, the usage of this EIP requires modification of the original route
    (insertion of an idempotentConsumer instruction before every destination
    endpoint) and I would prefer to use an alternative approach (if it's
    possible).

    Does the exchange keep information about which route endpoints have
    successfully processed it? Maybe it's the exchange's unit of execution
    holding this info?

    Thanks again for your help.

    Best regards,
    Atanas



    --
    View this message in context: http://camel.465427.n5.nabble.com/Avoiding-duplicate-messages-tp5746278p5746304.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Richard Kettelerij at Jan 21, 2014 at 9:09 pm
    Hi Atanas,
    However, the usage of this EIP requires modification of the original route
    (insertion of an idempotentConsumer instruction before every destination
    endpoint) and I would prefer to use an alternative approach (if it's
    possible).
    Why would modifying the route (e.g. inserting idempotent consumers) be a
    problem?
    Does the exchange keep information about which route endpoints have
    successfully processed it? Maybe it's the exchange's unit of execution
    holding this info?
    Take a look at the message history of the exchange:
    http://camel.apache.org/message-history.html

    Also as you can read on the above page you can also use the Java AP of the
    UnitOfWork:
    http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/TracedRouteNodes.html.
    E.g: exchange.getUnitOfWork().getTracedRouteNodes().getNodes().

    But I think using an idempotent consumer is easier.

    Kind regards,
    Richard

    On Tue, Jan 21, 2014 at 8:26 PM, Atanas Shindov wrote:

    Hi Richard,

    thanks for your prompt reply.

    It looks like the Idempotent Consumer might help, especially if in it's
    File/JDBC based implementations the message ids are durably persisted (it
    seems quite logical to be so), so that they are available after a JVM
    restart for example.

    However, the usage of this EIP requires modification of the original route
    (insertion of an idempotentConsumer instruction before every destination
    endpoint) and I would prefer to use an alternative approach (if it's
    possible).

    Does the exchange keep information about which route endpoints have
    successfully processed it? Maybe it's the exchange's unit of execution
    holding this info?

    Thanks again for your help.

    Best regards,
    Atanas



    --
    View this message in context:
    http://camel.465427.n5.nabble.com/Avoiding-duplicate-messages-tp5746278p5746304.html
    Sent from the Camel - Users mailing list archive at Nabble.com.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedJan 21, '14 at 1:12p
activeJan 21, '14 at 9:09p
posts4
users2
websitecamel.apache.org

People

Translate

site design / logo © 2022 Grokbase