Hi Dave,
Apologies for the delayed response again. This one's a bit tricky and
I'm still thinking about it. The only thing I'm sure of ATM is I'd
prefer a dedicated @Group annotation instead of the addition of group=""
to existing annotations. I think it allows better reuse and typesafety.
Generally I think the new annotation(s) should go into API, and generic
scanning code goes into SPI, delegating to SPI-defined interfaces which
are then implemented by providers (currently only QueuJ for the new
stuff). See how SeamCronExtension uses CDI to "scan" for observer
methods and delegates the processing to the CronSchedInstaller
interface, which is implemented by the quartz provider. If you have to
introduce a new interface/method (similar to CronSchedInstaller) not
handled by the existing providers and it causes them to stop building
properly that's fine, I can deal with that when I merge your pull
request. Just as long as API, SPI and your providers compile and pass tests.
Will try to have a more thorough response by COP tomorrow (so about
24hours from now).
Cheers,
Pete.
Dave Oxley wrote:
Hi Pete,
I have raised and am trying to implement SEAMCRON-33 which adds
concurrency control to Seam Cron. The API's I was thinking of
implement are:
@AsyncRestriction(group = "test_group")
public boolean canRun(StatusIndexes indexes) {
HasLessThan max = new HasLessThan(MAX_CONCURRENT);
max = indexes.iterateRunningProcesses(max);
indexes.iterateWaitingToRunProcesses(max);
return max.hasLess();
}
StatusIndexes will be an interface providing various methods to
interrogate the state of other jobs in the queue and true or false
should be returned to run or not run another.
And reference the group with a new attribute on the Asynchronous
annotation:
@Asynchronous(group = "test_group")
public void doWork() {
....
}
or a scheduled annotation:
public void every40Seconds(@Observes @Every(group = "test_group", nth
= 40, value = Interval.SECOND) Trigger t) {
....
}
I have a few questions:
1. Are you ok with the API changes? Do you have a better/different
idea for the API changes?
2. @AsynRestriction is a new feature for asynchronous or scheduling
methods. Therefore it doesn't really make sense to be a new spi. But
then if I implement it in the QueuJ scheduling and asynchronous as a
new feature it will just be an unimplemented feature for the Quartz
provider. How would you want this handled? Just document that it only
works for the QueuJ provider?
3. We will need to scan all classes on the classpath for methods
marked with the @AsynRestriction annotation at startup. Is there a
utility to do this or some example code?
Cheers,
Dave.