Orbeon Forms community mailing list

Dispatch with @delay firing multiple times

Classic

List

Threaded

7 messages Options

Dan Kereliuk

Dispatch with @delay firing multiple times

Hi, we have a submission being fired continuously in a loop, by using xf:dispatch with a 10-second delay. ie. something like this:

<xf:dispatch name="timer" target="timergroup" ev:event="DOMActivate"/>

<xf:group id="timergroup">
<xf:action ev:event="timer">
<xf:send submission="some-submission-here"/>
<xf:dispatch name="timer" target="timergroup" delay="10000"/>
</xf:action>
</xf:group>

It seems to run fine at first, but after leaving the page open for a while we notice in our logs that the submission begins firing twice per each 10 second interval, and then eventually 3 times, and so on until it's firing so many times that it actually starts affecting performance. It seems to start doing this randomly, so it sometimes takes a while to reproduce.

We're wondering if anyone else has experienced this, or if it's something that's been fixed in the latest version (we're currently using Orbeon Forms 3.8.0.201005141856 CE)?

Dan Kereliuk

Re: Dispatch with @delay firing multiple times

test-case.zip

Attached is a test case I just wrote up. You should be able to just extract it into the /apps/ folder and then navigate to that page under Orbeon. Instructions are included in the code, but it should be pretty straight-forward. Let me know if you have any trouble with it.

I've noticed that this problem seems to occur when interacting heavily with xforms controls on the page while the timed events are firing. Therefore I setup a simple page that displays the current time every 10 seconds by using the delayed dispatch, and included a xf:trigger that can be clicked rapidly to bring out the bug. Keep clicking that button non-stop and you should eventually start to notice the same time appearing multiple times per each 10-second interval.

Alessandro Vernet

Re: Dispatch with @delay firing multiple times

Administrator

In reply to this post by Dan Kereliuk

Dan,

This is because every time you click on the trigger, it starts a new sequence of "dispatch timer every 10 s", which happens in parallel to other sequences. I am not sure what you're trying to do, but if you'd like to have just one event every 10 s, and this to start the first time the button is pressed, when the button is pressed, set a flag in an instance, and before that dispatch the "timer" event only if the flag hasn't been set. This way, the second time the trigger is activated, you won't dispatch the event again.

Alex

--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

Dan Kereliuk

Re: Dispatch with @delay firing multiple times

Alessandro Vernet wrote

Dan,

This is because every time you click on the trigger, it starts a new sequence of "dispatch timer every 10 s", which happens in parallel to other sequences.

The trigger in our test case doesn't actually dispatch anything though. It's just a trigger with no actions tied to it, so it really shouldn't affect the sequencing at all. However, the test case demonstrates that it does affect it for some reason though.

Either way, we've just tried the test case in Orbeon 3.9 and this problem seems to be fixed in that version. So hopefully if we can get our problems with upgrading worked out (see our latest post), this won't be an issue anymore.

Alessandro Vernet

Re: Dispatch with @delay firing multiple times

Administrator

Hi Dan,

I'm glad to read this is indeed fixed and is working in 3.9. Were you able to do the upgrade? What is the status on the other issue you were mentioning?

Alex

--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

Dan Kereliuk

Re: Dispatch with @delay firing multiple times

We're still in the process of upgrading. Right now we're testing on our development server and it appears to be running fine. However, we've had to change large chunks of our code to work around some of the changed behavior between 3.9 and 3.8.

The first problem was with redirect responses being returned from the server after a POST request. GET requests worked, but POST would just show a blank page instead of redirecting. We've worked around this by returning an xml response which would be read and force a redirect indirectly from the client instead.

Next, there seems to be a change to how bind statements work. For example, for the following:
<xf:bind nodeset="instance('form')//*" required="true()">
<xf:bind nodeset="instance('form')/some-node" required="false()">

In 3.8, 'some-node' would not be required, because the second bind overrides the first. In 3.9, 'some-node' would be required, seemingly ignoring the second bind.

Erik Bruchez

Re: Re: Dispatch with @delay firing multiple times

Administrator

On the validation issue: the way things work at present is that
properties (MIPs) have a default value:

* required: false
* valid: true (depends on a series of conditions, including "required")
* relevant: true
* readonly: false

The resulting value of a property on a given node when multiple binds
touch that node is the result of a boolean combination:

* required: or
* valid: and
* relevant: and
* readonly: or

In other words the order of binds doesn't matter for a given property,
and a bind does not simply override another one,

I am guessing that this was different in 3.8, and that the change
occurred somewhere along the way to 3.9, following some discussions at
the XForms working group, as well as some work done with XPath
dependencies in the PE version.

I have updated the compatibility notes for 3.9 and added some
documentation on this:

http://wiki.orbeon.com/forms/doc/developer-guide/xforms-mips?pli=1#TOC-Multiple-binds-on-a-given-node

-Erik

On Fri, Oct 21, 2011 at 1:22 PM, Dan Kereliuk <[hidden email]> wrote:

> We're still in the process of upgrading. Right now we're testing on our
> development server and it appears to be running fine. However, we've had to
> change large chunks of our code to work around some of the changed behavior
> between 3.9 and 3.8.
>
> The first problem was with redirect responses being returned from the server
> after a POST request. GET requests worked, but POST would just show a blank
> page instead of redirecting. We've worked around this by returning an xml
> response which would be read and force a redirect indirectly from the client
> instead.
>
> Next, there seems to be a change to how bind statements work. For example,
> for the following:
> <xf:bind nodeset="instance('form')//*" required="true()">
> <xf:bind nodeset="instance('form')/some-node" required="false()">
>
> In 3.8, 'some-node' would *not* be required, because the second bind
> overrides the first. In 3.9, 'some-node' would be required, seemingly
> ignoring the second bind.
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Dispatch-with-delay-firing-multiple-times-tp3649476p3926675.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws