camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: [DISCUSS] Message Store
Date Wed, 24 Oct 2012 01:43:32 GMT
Hi Christian,

You are correct about the fact that a Message Store is missing (kinda). 
There are a few components that support a message store implementation 
of sorts, as you mentioned. You are also correct that it should be a 
first class citizen.

Practically, an endpoint that supports a polling consumer is a message 
store. What is actually missing is random access via a polling consumer. 
A message store would then work atop any endpoint that supports random 
retrieval (polling). That would create the opportunity to cleanup a bit 
the pollEnrich implementation as well.

My $0.02,

On 10/23/2012 07:18 AM, Christian Ohr wrote:
> Hi everyone,
> in the past I came several times across situations that required the
> one or other kind of Message Store. I noticed that in Camel this
> doesn't seem to be a "first class citizen" in the sense of a primary
> architectural concept, which can be applied consistently whereever
> needed.
> In short, it might make sense to have a unified, generic, pluggable
> Message Store (probably more of an "Exchange store") in Camel that
> consolidates the different approaches and allows to similarly
> parameterize persistence to various EIP patterns, and can be used
> independently of EIP patterns as well. Implementations would handle
> the mapping to the underlying database or file system or NoSQL or
> whatever.
> It seems that Spring Integration provides something corresponding
> (
> Message Store implementations are already used by Camel in various
> places, although using different approaches :
> * Stream Caching (only file system)
> * AggregationRepository (used for splitters, multicasts etc., but the
> interface is not specific at all to aggregation use cases)
> * IdempotentRepository
> Message Store is requested for in other places:
> * Reliable stream resequencing (CAMEL-949)
> * Persistent Dead Letter Queue (CAMEL-4575)
> And there might be other areas (seda, bam) that might benefit as well.
> Maybe generalizing the AggregationRepository is a way to go forward.
> Side note: The OeHF IPF platform (which is built on top of Camel and
> partly extends it to the health care domain) has something called a
> "Flow Manager" (
> that is used for tracking exchanges while they are processed or after
> processing is done, thereby being able to re-insert them into the
> route. Not that I consider this being a shining example, but it shows
> that message stores make sense outside their implicit use in EIP
> processors as well.
> Looking forward to your opinions!
> regards
> Christian

View raw message