camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From glenn <>
Subject QuartzScheduledPollConsumerScheduler, cluster and scheduler.triggerId
Date Tue, 01 Nov 2016 15:05:16 GMT
Am using a camel file consumer within a cluster to poll files on a periodic
basis. I wish to ensure that a consumer will only poll files if it has an
exclusive read lock on them so using the
QuartzScheduledPollConsumerScheduler with a readLock=idempotent read lock
strategy backed by a JdbcMessageIdRepository idempotentRepository.

I wanted to confirm that such an approach will ONLY work correctly in
cluster PROVIDED a unique triggerId is also assigned (ie assigned via use of
the QuartzScheduledPollConsumerScheduler scheduler.triggerId option)?

As where scheduler.triggerId is NOT assigned then a UUID is generated and a
unique job/trigger is created for EACH node resulting in > 1 file consumers
poll starting simultaneously.
For example in a cluster of two nodes with auto assigned UUID triggerId,
then two jobs will trigger against only one node each or both jobs against
one node. That scenario seems wrong in a cluster. 

BUT if a unique scheduler.triggerId is specified then only one job/trigger
will exist in DB and so quartz can ensure that the triggered job will only
ever work against one of the nodes at a time. That does seem to be the
desired behaviour.

So adopting the use of a scheduler.triggerId based approach does seem valid
but it does raise a question concerning the removal of the DB triggers/jobs
upon camel context shut down in a cluster so I wanted to check my
understanding before following up on that.

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message