8:23 a.m.
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
8:36 a.m.
New subject: Behaviour of EJB timer with intervall has changed AS5 -> AS7
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:53 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4775
days inactive
4775
days old
2 comments
2 participants
participants (2)
-
Jason Greene -
Wolf-Dieter Fink