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

["Claus Ibsen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-8973.
--------------------------------
    Resolution: Fixed
      Assignee: Claus Ibsen

Thanks

> 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
>            Assignee: Claus Ibsen
>             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)