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

["Jakub Korab (JIRA)" <ji...@apache.org>]

Jakub Korab created CAMEL-8973:
----------------------------------

             Summary: 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)