This issue has been added to the wsbpel issue list with a status
of "received".
The status will be changed to "open" if a motion to open the issue is
proposed and that
motion is approved by the TC. A motion could also be proposed to close
it without
further consideration. Otherwise it will remain as "received".
The issues list is posted as a Technical Committee document to the
OASIS
WSBPEL TC pages
on a regular basis. The current edition, as a TC document, is the most
recent version of the document entitled in the "Issues" folder of the WSBPEL
TC document list
- the next posting as a TC document will include this issue.
The list editor's working copy, which will normally include an issue
when it is announced, is available at this
constant URL.
Issue - 245 - Clarification on repeatEvery
Status: received
Date added: 28 Feb 2006
Categories: Specification
editing
Date submitted: 27 February 2006
Submitter: Mark
Ford
Description: The last sentence of Section 12.5.4.1. reads as
follows:
The repeatEvery alarm event is created repeatedly each
time the duration expires, while the associated scope is active.
It is possible that the execution of an onAlarm's child activity could
take longer than the value of its repeatEvery expression. Since
concurrent execution of a single onAlarm instance is not permitted (as
stated in 12.5.7) then the process would have to queue these onAlarm
executions and fire the onAlarm again once it has completed executing.
There are a few possibilities here:
- Avoid this issue by rescheduling the alarm each time the
activity within the onAlarm completes. The drawback is that depending
on the activities within the onAlarm it might not truly fire every N
seconds (or whatever its expression duration evaluates to).
- Allow the queuing of the onAlarms and consider the onAlarm
active until all of the queued alarms have been dispatched. This will
result in the scope waiting for the alarms to get delivered.
- Allow the queuing of the onAlarms but do not consider the
onAlarm active if it has queued alarms. The scope will not wait for the
onAlarm to process any queued alarms.
Submitter's proposal: I think option 3 is the right approach.
As such, I propose the following lines (in bold) be added to
section 12.5.4.1:
12.5.4.1. ALARM EVENTS
The counting of time for an alarm event with a duration starts
when the enclosing event handler is activated. An alarm event goes off
when the specified time or duration has been reached. Except for the
repeatEvery alarm, an alarm event is carried out at most once while the
corresponding scope is active; the event is disabled for the rest of
the activity of the corresponding scope after it has occurred and the
specified processing has been carried out. The repeatEvery alarm event
is created repeatedly each time the duration expires, while the
associated scope is active. Only a single instance of a repeatEvery
alarm is allowed to fire at one time. In the event that the
execution of the alarm takes longer than the specified repeatEvery
duration, then the scope will queue these alarms and dispatch them
immediately upon completion of the onAlarm's current execution. In the
event that the scope has completed its normal execution then the scope
will only wait for the currently dispatched alarm to complete and not
for any queued repeatEvery alarms.
Changes: 28 Feb 2006 - new issue
To comment on this issue (including whether it should be
accepted), please follow-up to this announcement on the
wsbpel@lists.oasis-open.org list (replying to this message should
automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - 245 -
[anything]" or is a reply
to such a message. If you want to formally propose a resolution to an
open issue, please start the subject line "Issue - 245 - Proposed
resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the
address for new issue submission is the sender of this announcement).
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php