まあ、私の最初の反射がfixedRate
オプションなしtimer
のperiod
オプションを使用することです(つまりはfalseにfixedRate
オプションを設定):その後、私はこのような何かだろうだから、
を、
from("timer:myTask?[other_options]&fixedRate=false")
.to("direct:lengthyProcessingRoute")
は、タスクが完了するのを待ってから、再度タイマーをトリガーする必要があります。例えば
、(fixedRate
はデフォルトでfalseです)のようなルートを宣言:
from("timer:sender?delay=5s&period=3s")
.log("Ping!")
.delay(5000)
.log("Ping2!");
はいつもの出力与える:
2016-08-26 12:36:48.130 INFO 5775 --- [ timer://sender] route1 : Ping!
2016-08-26 12:36:53.133 INFO 5775 --- [ timer://sender] route1 : Ping2!
2016-08-26 12:36:53.135 INFO 5775 --- [ timer://sender] route1 : Ping!
2016-08-26 12:36:58.138 INFO 5775 --- [ timer://sender] route1 : Ping2!
をしかし、これが唯一のあなたの長い処理ならば動作しますルートは本質的に同期しています。そうでなければ、JimNicholsonが提案しているものに似た何かをしなければならないでしょうin his answer。
あなたは時にタイマーが起動ルートがまだ実行されている場合に発生したいですか?タイマーの発射を無視して、次のタイマーが発進したときにルートが実行されるようにするか、またはルートが直前の呼び出しが終了して直後に実行されるのを待つべきですか? – JimNicholson
@JimNicholson私は無視したいと思います –