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: http://camel.465427.n5.nabble.com/QuartzScheduledPollConsumerScheduler-cluster-and-scheduler-triggerId-tp5789575.html Sent from the Camel - Users mailing list archive at Nabble.com.
