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.