Hi,
I'm seeing some surprising behaviour with my camel route, and was hoping
someone in this group could help, as my trawl through the docs and Camel In
Action book have not found the answers I'm looking for. Apologies if this
question has been clearly answered elsewhere :-/
I have a route that l
s Ibsen wrote:
> Hi
>
> See the parallelProcessing / executorService option on the aggregator
> http://camel.apache.org/aggregator2
>
> On Wed, Sep 18, 2013 at 2:49 AM, Baris Acar wrote:
>> Hi,
>>
>> I'm seeing some surprising behaviour with my camel
Thanks Claus. It is still verbose/error prone - I have to repeat it every time
I use such a processor (verbose) and I have to remember to do it (error prone).
And that assumes I *know* that I have to do it in the first place - I don't
know how I can tell whether a given processor holds a lock ar
Great, thanks Claus. I've attached a trivial unit test to the Jira issue
showing behaviour that should pass following the fix, which you're welcome to
include/adapt if it's useful.
Barış
> On 21 Sep 2013, at 11:34, Claus Ibsen wrote:
>
> Hi
>
> Yeah the sending to the thread pool could pote
Hi,
We have two instances of a service, one for low and one for high priority
users. Both post messages to a single shared queue, with the appropriate
priority level set so that high priority requests jump in front.
If the queue is completely full of low priority requests, it's impossible for
The comment in the link below - if true - indicates that the jms component
(which the activemq component is based on) is "not designed for batched
transactions" and doesn't support consuming multiple messages in a single
transaction; I don't know whether that also means it won't post a batch of
Hi,
We use camel in a standalone app which responds to a user request by sending
some messages via JMS. To aid with troubleshooting/support, we also save these
messages to disk using the 'file:' endpoint.
Unfortunately, since there are many tens of thousands of smallish (5-10KiB)
messages per
> the issue is that the Transaction Handling not happening and is rolling
back the transactions on exceptions.
What behaviour do you want/expect?
Rolling back on exception is a feature of using transactions. That's the
behaviour that's usually wanted.
—
Sent from Mailbox for i
Hi,
Is there a way to aggregate the first 100 messages from a seda if >=100 are
available, but just take however many are available if there are fewer?
I think I want aggregate(...).completionSize(100).completionTimeout(0), ie
complete on 100 items or 0, whichever condition is met "first", but I'
Timeout=0 is the very essence of what I'm trying to express, I'm not sure how I
can be both "correct" and "making no sense" :-)
I'd have guessed this was a common use case and would be a useful feature.
Consider a processor posting to a seda which consumes messages and posts them
in batch t
10 matches
Mail list logo