camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CAMEL-8973) Add Batching JMS component
Date Fri, 17 Jul 2015 10:54:05 GMT


ASF GitHub Bot commented on CAMEL-8973:

GitHub user jkorab opened a pull request:

    Camel 8973

You can merge this pull request into a Git repository by running:

    $ git pull CAMEL-8973

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #565
commit a3c51f4702ea3c24c767d6124b3bd9fb02a41a25
Author: jkorab <>
Date:   2015-07-16T10:32:29Z

    Merged in sjms-batch component.

commit c1d30da469272ec4f0e6c6f3c7ccf2d1c42544b0
Author: jkorab <>
Date:   2015-07-17T10:42:47Z

    Refactored logic around parsing destination names from the URI. Rejecting topics from
batch consumption, as does not make sense conceptually.


> Add Batching JMS component
> --------------------------
>                 Key: CAMEL-8973
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-sjms
>            Reporter: Jakub Korab
>             Fix For: 2.16.0
> Add specialised component that performs batch consumption of messages from a JMS destination
using local transactions.
> Pull request to follow.
> Original post to mailing list:
> --
> I have written a consumer-only component that combines aggregation logic
> with transacted JMS sessions that I would like to contribute. The
> component
> vastly speeds up message consumption and aggregation without message loss
> on failure when compared with using a regular JMS component and
> aggregator.
> The problem that it solves is that when you want to aggregate a set of
> messages from JMS and avoid message loss, you typically reach for a
> JdbcAggregationRepository. This in turn fetches and writes progressively
> larger blobs from the database on receipt of each message, slowing down
> linearly in relation to to the number of messages consumed - i.e. it
> performs progressively worse the larger the batch.
> Old way:
> from("jms:myQueue")
>      .transacted()
>      .aggregate(constant(true), myAggStrategy)
>          .aggregationRepository(jdbcAggregationRepository)
>          .completionSize(100)
>          .completionTimeout(500)
> This also suffers from a problem that message loss is still possible
> between the message broker and the database that stores the aggregated
> message (unless you use XA transactions....).
> The component that I have developed starts a JMS session, and receives
> messages synchronously until it meets a completion size, or until a
> completion timeout is met, each time calling an AggregationStrategy. Only
> when the completion conditions have been matched does it emit the
> aggregated message.
> The component will commit the batch transaction if the Exchange is
> processed successfully, or roll the entire thing back on exception - so
> all of the original messages will end up back on the queue for re-processing.
> In the event of failure of the Camel process, the messages remain on the
> broker for re-dispatch.
> So in terms of "where is my data stored?", the answer is it remains on
> thebroker until the batch is successfully processed.

This message was sent by Atlassian JIRA

View raw message