[jira] [Commented] (CAMEL-8973) Add Batching JMS component

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631180#comment-14631180 ] 

ASF GitHub Bot commented on CAMEL-8973:
---------------------------------------

GitHub user jkorab opened a pull request:

    https://github.com/apache/camel/pull/565

    Camel 8973

    https://issues.apache.org/jira/browse/CAMEL-8973

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

    $ git pull https://github.com/jkorab/camel CAMEL-8973

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

    https://github.com/apache/camel/pull/565.patch

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 <ja...@gmail.com>
Date:   2015-07-16T10:32:29Z

    Merged in sjms-batch component.

commit c1d30da469272ec4f0e6c6f3c7ccf2d1c42544b0
Author: jkorab <ja...@gmail.com>
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: https://issues.apache.org/jira/browse/CAMEL-8973
>             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
(v6.3.4#6332)