Hi
I have been working on a new Camel component for IronMQ. An elastic and
durable hosted message queue service see http://www.iron.io/products/mq.
Currently it only runs at AWS US East and Rackspace, but they are on the way
to support other regions as well. Have also seen it as a addon at Heroku
I fixed this issue by setting the option "delay=100" which makes sure the
first execution happens after 100ms. With the default, "delay=0", the first
execution is skipped some time by the TimerQueue.
Best,
Christian
On Sat, Sep 8, 2012 at 2:05 PM, Christian Müller <
christian.muel...@gmail.com> w
Yeah, after checking the java.util.TaskQueue source, there is a chance the
timer is not executed immediately, if the delay is 0. If it takes 1
millisecond or more to create the task and schedule it, the execution is
skipped the first time. This is may be also the issue for the other failing
task I
Ok, thanks for the explanation.
I'm working on another test [1] which fails which could be related to this.
It looks like if we do not specify a delay which is greater than 0, the
timer is executed the first time after "periode" of time. If the delay is
1, the timer get executed immediately the fir
I have removed initialDelay. It was added as a better name than delay,
because its only used once. But since the JDK * decided to call it
delay, then I decided to keep it as is. But the cwiki must have
up deleting. Well cwiki is not 100% up time, so I guess it could also
be that it was dow
>From [1] you can read:
delay 0 / 1000 The number of milliseconds to wait before the first event is
generated. Should not be used in conjunction with the time option. The
default value has bee n changed to 1000 from *Camel 2.11* onwards. In older
releases the default value is 0. initialDelay 1000
Claus, this commit breaks the AggregatorTimerAndTracerTest on CI server and
also my machine.
Could you please have a look at it.
[1]
https://builds.apache.org/view/A-F/view/Camel/job/Camel.2.10.x.fulltest/32/org.apache.camel$camel-core/testReport/org.apache.camel.processor.aggregator/AggregatorTim
+1
I will have a look at it and go ahead with the proposed changes (as I also
think this is Maven best practice).
Best,
Christian
On Fri, Sep 7, 2012 at 10:31 PM, Babak Vahdat
wrote:
>
> There's another weird thing by some Camel Maven modules as well, currently
> we've got 134-1 Camel POM module
