[seam-dev] Seam Cron Concurrency

[Pete Royle]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110706/45c72f31/attachment.html