Thanks, much appreciated.
Best,
Christian
On Wed, Aug 8, 2012 at 7:29 PM, Scott England-Sullivan
wrote:
> Chris,
>
> I should be able to have something ready to go in with the next set of
> updates. I will let you know when it is completed.
>
>
> On Tue, Aug 7, 2012 at 3:06 PM, Christian Müller
Hi Thomas,
A plug-able transaction strategy is definitely on the road map for the
future. I will have to take a look and see what short term options might
work for this.
On Wed, Aug 8, 2012 at 1:29 PM, Scott England-Sullivan
wrote:
> Chris,
>
> I should be able to have something ready to go i
Chris,
I should be able to have something ready to go in with the next set of
updates. I will let you know when it is completed.
On Tue, Aug 7, 2012 at 3:06 PM, Christian Müller <
christian.muel...@gmail.com> wrote:
> This is at least "my" requirement.
>
> Sent from a mobile device
> Am 07.08.
Maybe use a groupedExchange, see: http://camel.apache.org/aggregator2.html ?
2012/8/7 Thomas Johansen :
> I'm not sure what this implies, Scott.
>
> My use case is to have a transaction started on a first exchange, and then
> have X exhanges on the same transaction. It should first be committed w
Actually I would like a more flexible solution, like using some kind of a
strategy or maybe a route policy or something to trigger the commit (I'm
not aware of all mechanisms existing in Camel that might be suiting here).
My use case is not completely defined yet, but something like this:
1. Assu
This is at least "my" requirement.
Sent from a mobile device
Am 07.08.2012 18:47 schrieb "Scott England-Sullivan" :
> Hi Thomas,
>
> It sounds like you are looking for something like the following:
>
> from("sjms:consumer?transacted=true&batch=100")
> .processor("do stuff")
> to("file:output");
>
We try to cut a minor release every 3 month. The last release (2.10.0) was
cut after ~5 month, if I remember right.
This means we doesn't have a fix schedule for it.
Sent from a mobile device
Am 07.08.2012 15:26 schrieb "Scott England-Sullivan" :
> Christian,
>
> What is the proposed cut off dat
Hi Thomas,
It sounds like you are looking for something like the following:
from("sjms:consumer?transacted=true&batch=100")
.processor("do stuff")
to("file:output");
Such that 100 messages would be consumed, processed and filed followed by
the session either being committed or rolled back based
I'm not sure what this implies, Scott.
My use case is to have a transaction started on a first exchange, and then have
X exhanges on the same transaction. It should first be committed when some
external event happens, like a control message is seen (possibly from a
separate control queue), afte
Christian,
What is the proposed cut off date for 2.11?
On Aug 7, 2012, at 6:21 AM, Christian Müller
wrote:
> +1
> Would like to see this feature too...
>
> Sent from a mobile device
> Am 07.08.2012 10:49 schrieb "Thomas Johansen" :
>
>> Hi,
>>
>> As I understand the JMSComponent/ActiveMQCom
I will take a look at it tonight. Plan is to add batch support by having
the Producer and Consumer endpoints support a List of Messages. Once in
place TX would be automatically supported as it is called as a
Synchronization upon completion of the Exchange.
Thoughts?
On Tue, Aug 7, 2012 at 6:21
+1
Would like to see this feature too...
Sent from a mobile device
Am 07.08.2012 10:49 schrieb "Thomas Johansen" :
> Hi,
>
> As I understand the JMSComponent/ActiveMQComponent cannot support batched
> transactions due to the use of Spring's DMLC. With this new SJMSComponent
> there should be poss
Hi,
As I understand the JMSComponent/ActiveMQComponent cannot support batched
transactions due to the use of Spring's DMLC. With this new SJMSComponent
there should be possibilities to implement this, I guess?
BR,
Thomas
13 matches
Mail list logo
