5 Replies Latest reply on Sep 26, 2012 8:18 PM by Sham HC

    SlingPostProcessor and JCR Search Results...caching?

    Ryan Lunka Level 3

      I've implemented a SlingPostProcessor in CQ5.4 to intercept certain POST submits from a dialog.  The dialog allows the user to add a list of items, then the PostProcessor automatically assigns an ID to the list items before adding the new nodes.  If an item with the same name exists in the system, then it will use the existing ID.  If not, it will generate a new one based on what is currently in the repository.  It's a less-than-ideal design, but unfortunately I can't avoid having to implement this way to work around dirty data, plus it's too late to change the dialog to a different "page-oriented" implementation.  Anyway...


      In the PostProcessor I perform a JCR query to retrieve all of the existing similar nodes so that I can determine a) does the name exist yet with an assigned ID and b) if not, what will the next ID be.  This all works fine on the first POST to create a new item.  However, when I try to run the same operation again (to add another item to the list in the dialog), the second JCR query results do not seem to include the new node created in the first execution of the PostProcessor.


      I've tried two implementations, one using the CQ QueryBuilder API.  The behavior here is that my query returns a set of hits and some of them (it appears to be the "new" ones, but I cannot verify) have no path, Resource, or anything in them.  They are like empty Hit objects.  They either throw an exception when I try to access the Resource or I skip over them, and I continue to regenerate the same "next" ID every time I run the PostProcessor - because it's never aware of "new" nodes.  I also tried using the JCR query API (which I understand the QueryBuilder API just wraps) and the behavior is similar, but slightly different.  In this case, the NodeIterator in the QueryResult just simply doesn't have what should be the "new" nodes.  Same problem - I keep regenerating the same ID.


      I understand that Apache Jackrabbit does some kind of caching of JCR search results, so I wondered if that was the issue and what I can do to work around it.  Will invoking the query with a new session every time take care of it?  How can I bypass this cache?  Or am I off base and this appears to be an issue NOT related to caching - perhaps something with the Lucene index?


      Does anyone have any thoughts to offer?  Thanks a lot!

        • 1. Re: SlingPostProcessor and JCR Search Results...caching?
          Sham HC Level 7

          Does the new node created searchable from any query tools like crxde, querydebug? 

          My first suspect would be is node getting indexed.  Verify the index settings if by any chance you are restricting.

          • 2. Re: SlingPostProcessor and JCR Search Results...caching?
            Ryan Lunka Level 3

            Yes, I do see the new node in CRXDE and in the Query Debugger.  Did you mean your "first suspect is that the node is NOT getting indexed?"  Could you provide any advice as to what I should be looking for in the index settings?

            • 3. Re: SlingPostProcessor and JCR Search Results...caching?
              Jörg Hoh Adobe Employee

              Indexing nodes is a synchronous acitivity during the write (exception to that rule: large binaries are index async).

              • 4. Re: SlingPostProcessor and JCR Search Results...caching?
                Ryan Lunka Level 3

                Sham, I checked out the indexing settings.  The only thing that jumped out at me was the <aggregate primaryType="cq:PageContent"> tag that contains a bunch of children which describe how "deep" to index a page node.  It's possible this is affecting the system's ability to index these "new" nodes added by the PostProcessor, because they are created 6 levels beneath a cq:PageContent (jcr:content) node and the default setting here was 4 levels.  I added a few more levels to this aggregate node, so that it can index 7 levels deep and it did not seem to have an effect.


                I'm wondering, though, if this is still the right track.  First, when I change indexing settings in this file, all I should have to do is restart the instance, right?  Is there anything else I would need to do to ensure the changes are taken into efffect?  Second, I'm thinking that I can use the <aggregate /> tag to be a bit more specific about expecting the system to index my "new" nodes.  The problem is, the big data structure my new nodes are part of is made up of only "nt:unstructured" nodes.  Is there a way to specify an aggregate using node name or some identifier other than "primaryType"?  I didn't see this readily explained in the Jackrabbit indexing documentation.  If I could specify an aggregate based on primaryType="nt:unstructured" and node name="my:NodeName", I think I could create a specific enough aggregate tag to possibly resolve the problem.


                Does any of this sound valid, or am I going down a rabbit hole?  I appreciate the help guys.


                By the way, jhoh@adobe.com, I'm with you on the synchronous indexing.  That's what I expected, which is why I'm confused as to why subsequent JCR queries do not account for the "new" nodes.

                • 5. Re: SlingPostProcessor and JCR Search Results...caching?
                  Sham HC Level 7

                  If you are able to get results by searching from  CRXDE and in the Query Debugger.  It should be correct because be default all nodes & properties are indexed.Does not make sense to look into indexing configuration.

                  This looks strange, it should work. Could you please post a code or file a daycare so that i can take a look.