As of 2.2, Camel does have a " http://camel.apache.org/graceful-shutdown.html
graceful shutdown " and allows you to configure the amount of time to wait
for inflight messages to complete, etc...
also, you should the
http://camel.465427.n5.nabble.com/Camel-Users-f465428.html camel-users list
for
consider using an http://camel.apache.org/intercept.html intercept strategy
...
use the camel-users list for these going forward...
rahulbhatt04 wrote:
>
> Hi
>
> I have a requirement to store every message that goes from Camel to the
> database. My implementation is Camel using Spring. I ha
Christian, great question...I see various forms of this asked many times.
I've considered all the options you mentioned, but for high-volume/critical
messaging scenarios, I struggle with the idea of leaving messages up to the
AMQ config/inflight repositories for lack of control/visibility/testabil
+1
hadrian wrote:
>
> A new minor release apache-camel-2.8.0 is out with approximately 420
> issues resolved: improvements and bug fixes [1]. This is a release with a
> record number of fixes and reflects the increased popularity of Apache
> Camel and our growing community.
>
> Please review, t
hey guys, while working on a solution for a client, I ran into the need to
"synchronize" multiple routes that modify the same data (users, orders, etc)
to prevent collisions (stale writes, etc). Is there an existing way to do
this that I've overlooked?
In the past, I've relied on http://active
thanks for the feedback. I agree that this needs more consideration and may
not even be a good fit for Camel (hence this post). I do feel like this is
becoming a more common use case given the trend towards more
concurrent/distributed solutions (clustering, cloud deployments, big data,
etc). AMQ
uitable
> to impement this and what parameters would we need?
> Does Hazelcast support this scenario?
>
> Would we start and stop the route when it gets or looses the lock?
>
> Christian
>
> Am 06.09.2011 22:16, schrieb boday:
>> hey guys, while working on a soluti
Zbarcea wrote:
>
>> Ben, no issue with the term lock(), I get the semantics. What I don't get
>> is this: what happens in your scenario if one of the boxes crashes (say
>> physically, burnt memory chip, power supply explodes) with the lock
>> acquired. What do the other ca
Bilgin, I'm still reviewing/enhancing the camel-solr component you submitted.
I'm pretty close, just trying to add the necessary support to get it to work
in osgi (karaf, etc).
Bilgin Ibryam wrote
>
> Hi all,
>
> A week ago I submitted a camel-cmis component [1] but didn't described
> it he
I'd like to get the new camel-solr (CAMEL-4539) component into 2.9 if
possible. I can get this in today...let me know if anyone has any issues
with this...thx
-
Ben O'Day
IT Consultant -http://consulting-notes.com
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-C
Christian, I also updated the karaf solrj-bundle-version to the newly
released 3.5.0_1 bundle
Christian Mueller wrote
>
> The vote for the SMX bundles released passed and the artifacts has been
> promoted to central repo.
> I will start to work on my two outstanding issues for Camel 2.9.0...
>
> This may happen when you change the DSL.
> If I remember myself then I try to run a full test of camel-scala. But
> it may slip my mind sometimes, and then later i bites you :)
>
>
>
> On Mon, Jul 16, 2012 at 7:51 PM, <boday@> wrote:
>> Author: boday
currently its implemented to only look for a header
(Exchange.AGGREGATION_COMPLETE_ALL_GROUPS) in a "signal" message and
excludes that message...
it was mentioned in the following SFO post to have the option to be
inclusive of the current message instead of just using it as a signal
message...seem
thanks for the feedback guys, created the following ticket and will add
support soon:
https://issues.apache.org/jira/browse/CAMEL-6119
-
Ben O'Day
IT Consultant -http://consulting-notes.com
--
View this message in context:
http://camel.465427.n5.nabble.com/aggregator-force-completion-with
14 matches
Mail list logo