Bug 780363 (SOA-2772)

Triage on 1/14: release note item

Release Notes Docs Status: Added: Documented as Known Issue
Release Notes Text: Added: The sequencing is done in a separate thread (right away after the session is saved from uploading the content).  And after the sequencing saves it's content, the indexing thread runs.    Therefore, depending on how slow the box is, the user may have to wait several seconds before the full-text search will find the related data.

The problem is not that items are not found but that the item is found before all its parents are created which results in an exception.

I have a guess that the fix for SOA-2722 will hide that away but it looked to me strange that the nod is found by the search an path to it is not existing.

I have tested ER7 thoroughly and cannot reproduce this problem. If you believe order of creating of nodes by sequencers doesn't lead to any other issues feel free to close this JIRA issue.

Thank you.

Link: Added: This issue related SOA-2722

I also notice another interesting behavior that's worth looking at.

{code}
      ftsResult = ftsQuery.execute();

      // wait for data to be sequenced
      for (int i = 0; i <= 100; i++) {
         ir = ftsResult.getRows();
         out.println("iteration: " + i);
         if (ir.hasNext()) break;
         if (i == 100) throw new ServletException("10 seconds not enough to sequence the file");
         Thread.sleep(100);
      }
{code}

As you see from the code above (yes, I made a mistake), I execute query just once before the loop. My application output shows that the check succeeds after a few iterations of the loop. So it seems like after awhile getRows() and getNodes() return a different result than initially. I think that this is a consequence of the changes from SOA-2722.

From what I see things happen like:
1. File node inserted into repo.
2. data is sequenced and inserted into repo but still not all parent nodes of sequenced data created (or some other inconsistency?)
3. My query finds the sequenced data
4. queryResult.getNodes() returns nothing (because of SOA-2722 ?)
5. After awhile sequencer finally puts the sequenced data Nodes in a consistent state
5. queryResult.getNodes() starts returning nodes

Although JCR2 API anticipates an exception if getRows() or getNodes() is called for the second time on a QueryResult (http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/query/QueryResult.html#getRows()), I don't think that is a problem for modeshape.
I don't have deep modeshape knowledge so I'd ask you to look and consider if this behavior could be problematic in some use cases, for example within transactions?

IMHO ideally all these possible cases where multiple threads are creating and querying data, should be covered by modeshape test cases perhaps with the help of www.jboss.org/byteman so operations ordering is well controlled.

Interesting. The section 6.12.3 of the JCR 2.0 specification specifies the behavior that the QueryResult (row values and Node references) reflect the state of the transient session. Here's a quote from this section:

    "Regardless of which scope is used, when an item is accessed from within a QueryResult object, 
    the state of the item returned will obey the same semantics as if it were retrieved using a normal 
    Node.getNode or Node.getProperty: the item state will reflect any pending changes in transient 
    store of the Session. As a result, it is possible that an item returned as a match will not reflect the 
    state that caused it to be a match (i.e., its persistent state). Applications can clear the Session 
    (either through save or refresh(false)) before running a query in order to avoid such discrepancies."

We don't have a problem with users calling getRows() more than once. I don't see anything in the specification about that restriction, but as you point out it is in the JavaDoc. I guess I'll log that as an issue with ModeShape and change the code to throw the exception. Unfortunately there is no 'close()' mechanism on the QueryResult; that should really be the signal that you can't call methods on the result set. Barring that, throwing the exception as described in the JavaDoc is probably the only way to prevent accidental errors like yours.

I think I understand. I also read the query and queryresult sections in the spec and I don't see anything modeshape violates specification with, so please consider this issue *not* a blocker for SOA-P.

I hope though to have modeshape behavior covered by test cases in the upstream project (if not already done) so any changes in behavior (although non violating the specification) wont go unnoticed and will be communicated to modeshape/SOA-P users. If you like I can file a MODE-* jira issue for that.

Thank you for looking into this!

I understand about this not being a blocker.

I would love to have additional test cases in the upstream project, so if you have any to contribute, please let us know by logging an issue and providing the tests. If possible, add them to the codebase yourself (see the instructions on http://community.jboss.org/wiki/ModeShapeDevelopmentWorkflow for details on how to contribute).

Affects: Added: [Release Notes]