[jboss-as7-dev] Behaviour of EJB timer with intervall has changed AS5 -> AS7

[Wolf-Dieter Fink]

cron is simple, if its up the event fire if not, NOT.
So I think the behaviour is different to that what I expect from EJB 
(and the spec), the event must at minimum fired once.

For the interval timer I would prefer the same behaviour as in AS5, it 
will make the migration support of SEG easier ;)

For the calendar timer I'm not sure,
concurrent might not what the customer expect or hope.
And the idea for persistent c-timer might be that after start 'fire it 
one time is enough'

If you have long period (e.g. once a day/week) I hope that there is 
never be such long downtime that the timer is run twice after start;)
But customers might have the idea to schedule every x minutes in some 
cases and then concurrent or catch up after downtime might not what is 
wanted.


On 12/16/2011 03:36 PM, Jason Greene wrote:
> Good questions. Perhaps we should compare with cron, quartz, etc
>
> Sent from my iPhone
>
> On Dec 16, 2011, at 8:23 AM, Wolf-Dieter Fink<wfink at redhat.com>  wrote:
>
>> I've tested the behaviour of AS7 timer during bug fixing.
>> And now I need to discuss and clarify how the behaviour in AS7 should be.
>>
>>
>> There is a big difference in case of overlapping timers between EAP5.1
>> (and earlier, I don't check AS6) and AS7.
>>
>> ISSUE:
>> If a timer is longer active as the interval, the time-out was delayed as
>> long as the running timer is active.
>> With AS7 the time-out method will be executed and run concurrent!
>>
>> I see migration issues because the application may rely on the non
>> concurrent behaviour.
>>
>> QUESTIONS:
>> The fix looks simple.
>> But I want to clarify whether there is a counter-argument
>>
>> 1) recurring (interval) timer
>> A interval timer should not be called until it is still running
>> =>  there is no WARN/INFO should we add it?
>>
>> 2) calendar timer
>> Should a calendar timer delayed also if the period between time-outs is
>> to short?
>> =>  I would prefer a WARN message if the timer is dropped
>>
>> What about catch up on startup if the timer is persistent.
>> ATM all events are fired in parallel if there are more.
>> (This will be a nice ERROR party in the log file in case of
>> SingletonBeans with default WRITE lock.)
>> =>  Drop it with a warning
>> =>  block it until the first is finished
>>
>>
>> regards
>> Wolf
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev