XPL for-each behavior

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

XPL for-each behavior

wreeder
I understand that the for-each element causes the execution of included processors once per item returned from the for-each's select attribute. However, I found today that if a processor inside of the for-each accesses an id from outside of the for-each, it also executes all processors used to create the referenced id. For example, I uses a sql processor outside of the for-each element to load data required by the for-each. I expected the sql processor to execute once since it is located outside of the for-each. However, it executes multiple times, once per item defined by the for-each's select attribute.

Is this expected behavior?

By the way, I was able to stop this behavior by adding a null-serializer after the sql processor to consume the id output of the sql processor before executing the for-each, and it stops the sql processor from executing multiple times. I can use this pattern elsewhere, but the behavior is subtle, and hard to find.

Thanks for any help on this issue.

-Bill
Reply | Threaded
Open this post in threaded view
|

RE: XPL for-each behavior

Steve Bayliss
This does sound odd - I'd expect the SQL processor to be executed only once.

Do you have any debug attributes in any of your pipelines?  This affects
caching behaviour I believe, maybe that's triggering it?

-----Original Message-----
From: Bill Reeder [mailto:[hidden email]]
Sent: 04 November 2008 22:20
To: [hidden email]
Subject: [ops-users] XPL for-each behavior



I understand that the for-each element causes the execution of included
processors once per item returned from the for-each's select attribute.
However, I found today that if a processor inside of the for-each accesses
an id from outside of the for-each, it also executes all processors used to
create the referenced id. For example, I uses a sql processor outside of the
for-each element to load data required by the for-each. I expected the sql
processor to execute once since it is located outside of the for-each.
However, it executes multiple times, once per item defined by the for-each's
select attribute.

Is this expected behavior?

By the way, I was able to stop this behavior by adding a null-serializer
after the sql processor to consume the id output of the sql processor before
executing the for-each, and it stops the sql processor from executing
multiple times. I can use this pattern elsewhere, but the behavior is
subtle, and hard to find.

Thanks for any help on this issue.

-Bill
--
View this message in context:
http://www.nabble.com/XPL-for-each-behavior-tp20332526p20332526.html
Sent from the ObjectWeb 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
Reply | Threaded
Open this post in threaded view
|

RE: XPL for-each behavior

wreeder
I removed all the debug attributes, and the behavior is the same.

It looks like the for-each statement is not using the scope of the for-each block to determine what processors it runs in the loop.

Steve Bayliss wrote
This does sound odd - I'd expect the SQL processor to be executed only once.

Do you have any debug attributes in any of your pipelines?  This affects
caching behaviour I believe, maybe that's triggering it?

-----Original Message-----
From: Bill Reeder [mailto:wreeder@delphi-tech.com]
Sent: 04 November 2008 22:20
To: ops-users@ow2.org
Subject: [ops-users] XPL for-each behavior



I understand that the for-each element causes the execution of included
processors once per item returned from the for-each's select attribute.
However, I found today that if a processor inside of the for-each accesses
an id from outside of the for-each, it also executes all processors used to
create the referenced id. For example, I uses a sql processor outside of the
for-each element to load data required by the for-each. I expected the sql
processor to execute once since it is located outside of the for-each.
However, it executes multiple times, once per item defined by the for-each's
select attribute.

Is this expected behavior?

By the way, I was able to stop this behavior by adding a null-serializer
after the sql processor to consume the id output of the sql processor before
executing the for-each, and it stops the sql processor from executing
multiple times. I can use this pattern elsewhere, but the behavior is
subtle, and hard to find.

Thanks for any help on this issue.

-Bill
--
View this message in context:
http://www.nabble.com/XPL-for-each-behavior-tp20332526p20332526.html
Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com.




--
You receive this message as a subscriber of the ops-users@ow2.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@ow2.org
For general help: mailto:sympa@ow2.org?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

RE: XPL for-each behavior

Alessandro Vernet
Administrator
Bill,

Bill Reeder wrote
It looks like the for-each statement is not using the scope of the for-each block to determine what processors it runs in the loop.
This is not an intended behavior. Said otherwise, it is a bug. Woo-how, it has been a long time since we have seen the last bug in the XPL engine :). When creating the objects that represent the pipeline in memory, we need to add a "Tee" to any output read from inside the for-each (unless there is one already). The Tee is keeping the read XML in a SAX store, so in case it is read again, it will be served from the SAX store instead of requiring the output it is connected to be re-read. I added this bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=311723&group_id=168&atid=350207

For now, the workaround is, like you did, to add a null-serializer outside of the for-each which reads the same output. In that case, the pipeline engine will "see" that this output is read by multiple processors and will add the Tee.

Alex
Reply | Threaded
Open this post in threaded view
|

RE: XPL for-each behavior

Erik Bruchez
Administrator
All,

We have added the "Tee" processors mentioned in this thread, and this bug should now be fixed.

-Erik

Alessandro Vernet wrote
Bill,

Bill Reeder wrote
It looks like the for-each statement is not using the scope of the for-each block to determine what processors it runs in the loop.
This is not an intended behavior. Said otherwise, it is a bug. Woo-how, it has been a long time since we have seen the last bug in the XPL engine :). When creating the objects that represent the pipeline in memory, we need to add a "Tee" to any output read from inside the for-each (unless there is one already). The Tee is keeping the read XML in a SAX store, so in case it is read again, it will be served from the SAX store instead of requiring the output it is connected to be re-read. I added this bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=311723&group_id=168&atid=350207

For now, the workaround is, like you did, to add a null-serializer outside of the for-each which reads the same output. In that case, the pipeline engine will "see" that this output is read by multiple processors and will add the Tee.

Alex