I’d prefer to be able to pass identifier to the scheduler and get it back in the handler. The need to pass some context object and predicate to cancel schedule looks inefficient to me - scheduler will need to use context and predicate to compare context to all existing contexts, rather than efficiently retrieving one by key. Also I not sure quartz supports something like this.
See for example http://www.quartz-scheduler.org/api/2.2.1/org/quartz/Scheduler.html#deleteJob(org.quartz.JobKey)
By the way, I think it will be convenient to extend axon’s scheduler api to support groups, as for example when aggregate has several jobs scheduled, deleting aggregate should delete all its jobs at once, so groups can be handy, to prevent remembering/iterating individual schedule tokens.
After all, these are easy to implement aside of Axon.
There’s other problem with scheduler and distributed command bus. Simple scheduler implementation is transient, and quartz scheduler does not support consistent hashing for job distribution to always schedule job to the node, matched by consistent hash, rather quartz schedules it to arbitrary node. Thus, currently any node can receive event from distributed scheduler, then event handler can use distributed command bus to route it to correct node. If you don’t plan to use command bus to deliver commands from scheduler to aggregates, then there should be implemented similar mechanism, to either route deadline to the correct node, or add support of persistence and recovery to simple scheduler, so that every node recovered only schedules matcing to consistent hash.