directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Created: (DIRSNICKERS-46) Rules fire in (pseudo) parallel mode
Date Sat, 29 May 2004 05:15:00 GMT
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


Mime
View raw message