You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by ji...@apache.org on 2004/05/29 07:15:00 UTC
[jira] Created: (DIRSNICKERS-46) Rules fire in (pseudo) parallel mode
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIRSNICKERS-46
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIRSNICKERS-46
Summary: Rules fire in (pseudo) parallel mode
Type: Bug
Status: Open
Priority: Minor
Project: Directory Snickers
Components:
BER Runtime
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Fri, 28 May 2004 10:14 PM
Updated: Fri, 28 May 2004 10:14 PM
Description:
Rules added to the digester's rule base using the same pattern are fired together at the same: all rules for the same pattern have tag() called on a match first together, then length(), then value() and finally finish(). So if r1, r2, and r3 are added to the rule base using the same pattern then the sequence of rule method invokations for a match would be:
r1.tag()
r2.tag()
r3.tag()
r1.length()
r2.length()
r3.length()
============================================
-- seq of calls might more than one times --
r1.value()
r2.value()
r3.value()
============================================
r1.finish()
r2.finish()
r3.finish()
This may cause unusual behavoir since we presumed the sequential operation of rules on the same pattern. So we supposed the invokations would look like so:
r1.tag()
r1.length()
[r1.value()]* - might occur one or more times
r1.finish()
r2.tag()
r2.length()
[r2.value()]* - might occur one or more times
r2.finish()
r3.tag()
r3.length()
[r3.value()]* - might occur one or more times
r3.finish()
We discovered this problem when the LDAP Result errorMessage rule and the matchedDN rules were overwriting one another. These two fields have the same nesting patterns and come right after one another with the matchedDN field first. What was happening was both were firing for each field that arrived. So when the matchedDN appeared both fired and the errorMessage of the LDAP result was set to the
matchedDN value and the matchedDN of the LDAP result was set correctly however when the errorMessage arrived and triggered the two rules to fire again this time the matchedDN of the LDAP result was set to the errorMessage and the errorMessage field was now set correctly. This is not an idea situation. There may need to be some way to alternate rules within a TagNode so that alternate across pattern matches. This way two different matches in time with the same pattern can be matched by two different rules.
We need to think about this for some time. Changes may not be needed if there seems to be no use case requirements, however I doubt that.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (DIRSNICKERS-46) Rules fire in (pseudo) parallel mode
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://nagoya.apache.org/jira/browse/DIRSNICKERS-46?page=history ]
Alex Karasulu closed DIRSNICKERS-46:
------------------------------------
Resolution: Fixed
also fixed ages ago
> Rules fire in (pseudo) parallel mode
> ------------------------------------
>
> Key: DIRSNICKERS-46
> URL: http://nagoya.apache.org/jira/browse/DIRSNICKERS-46
> Project: Directory Snickers
> Type: Bug
> Components: BER Runtime
> Reporter: Alex Karasulu
> Assignee: Alex Karasulu
> Priority: Minor
>
> Rules added to the digester's rule base using the same pattern are fired together at the same: all rules for the same pattern have tag() called on a match first together, then length(), then value() and finally finish(). So if r1, r2, and r3 are added to the rule base using the same pattern then the sequence of rule method invokations for a match would be:
> r1.tag()
> r2.tag()
> r3.tag()
> r1.length()
> r2.length()
> r3.length()
> ============================================
> -- seq of calls might more than one times --
> r1.value()
> r2.value()
> r3.value()
> ============================================
> r1.finish()
> r2.finish()
> r3.finish()
> This may cause unusual behavoir since we presumed the sequential operation of rules on the same pattern. So we supposed the invokations would look like so:
> r1.tag()
> r1.length()
> [r1.value()]* - might occur one or more times
> r1.finish()
> r2.tag()
> r2.length()
> [r2.value()]* - might occur one or more times
> r2.finish()
> r3.tag()
> r3.length()
> [r3.value()]* - might occur one or more times
> r3.finish()
> We discovered this problem when the LDAP Result errorMessage rule and the matchedDN rules were overwriting one another. These two fields have the same nesting patterns and come right after one another with the matchedDN field first. What was happening was both were firing for each field that arrived. So when the matchedDN appeared both fired and the errorMessage of the LDAP result was set to the
> matchedDN value and the matchedDN of the LDAP result was set correctly however when the errorMessage arrived and triggered the two rules to fire again this time the matchedDN of the LDAP result was set to the errorMessage and the errorMessage field was now set correctly. This is not an idea situation. There may need to be some way to alternate rules within a TagNode so that alternate across pattern matches. This way two different matches in time with the same pattern can be matched by two different rules.
> We need to think about this for some time. Changes may not be needed if there seems to be no use case requirements, however I doubt that.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira