Session.save() and Observation listeners in a SlingAllMethodsServlet

[Lukas Eder <ma...@adobe.com>]

I feel that I have stumbled upon a very subtle bug or API misuse on my
side when using SlingAllMethodsServlet. The following is a shortened
version of my code:

    @Override
    protected void doPost(
        SlingHttpServletRequest request,
        SlingHttpServletResponse response
    ) throws ServletException, IOException {

        // [...]
        Resource resource = request.getResource();
        Node node = resource.adaptTo(Node.class);
        node.setProperty("x", "y");
        node.getSession().save();
        // [...]

    }



Now, through debugging, I have noticed that the change I made above did
not update Jackrabbit's index. Before I try to write up a reproducible
test case:

1. Is this a known issue?
2. Am I misusing API (e.g. session.save())?

I've noticed that Sling's PostOperation uses ResourceResolver.commit(),
although that doesn't seem to make the difference.

Cheers
Lukas

Re: Session.save() and Observation listeners in a SlingAllMethodsServlet

[Lukas Eder <ma...@adobe.com>]

Hi Alex,


On 6/18/13 1:39 PM, "Alexander Klimetschek" <ak...@adobe.com> wrote:

>The JCR spec mandates that an update after a session save() is
>immediately visible to JCR queries after save() [0]. This is true for
>normal property updates. So your code looks fine.
>
>The exception are full text index updates i.e. from binary files, which
>are done asynchronously if they are too slow (> X ms I think), as the
>full text extraction should not block things - it isn't something that a
>programmatic query (that you might have directly after a session.save())
>could rely on anyway.
>
>[0] http://www.day.com/specs/jcr/2.0/6_Query.html#6.5%20Search%20Scope

I thought about that, but that's not the problem here. It's really because
of my wrong tampering with aggregate rules. The issue is solved for me.

There was actually an inconsistency between the implementations of:

- AggregateRule.getAggregateRoot()
- AggregateRule.getAggregatedNodeStates()

This lead to the differing behaviour, depending on the call trace, as
there seems to be some subtle redundancy in Jackrabbit with respect to
execution flows in that area. Just bad luck on my side :-)

Thanks,
Lukas

Re: Session.save() and Observation listeners in a SlingAllMethodsServlet

[Alexander Klimetschek <ak...@adobe.com>]

The JCR spec mandates that an update after a session save() is immediately visible to JCR queries after save() [0]. This is true for normal property updates. So your code looks fine.

The exception are full text index updates i.e. from binary files, which are done asynchronously if they are too slow (> X ms I think), as the full text extraction should not block things - it isn't something that a programmatic query (that you might have directly after a session.save()) could rely on anyway.

[0] http://www.day.com/specs/jcr/2.0/6_Query.html#6.5%20Search%20Scope

Cheers,
Alex

Re: Session.save() and Observation listeners in a SlingAllMethodsServlet

[Lukas Eder <ma...@adobe.com>]

On 6/18/13 12:37 PM, "Robert Munteanu" <ro...@apache.org> wrote:

>>     @Override
>>     protected void doPost(
>>         SlingHttpServletRequest request,
>>         SlingHttpServletResponse response
>>     ) throws ServletException, IOException {
>>
>>         // [...]
>>         Resource resource = request.getResource();
>>         Node node = resource.adaptTo(Node.class);
>>         node.setProperty("x", "y");
>>         node.getSession().save();
>>         // [...]
>>
>>     }
>
>
>The code looks fine to me, although I'd advise just using the Resource
>API if possible, since you already have the resource at hand.

I simplified the example. The actual code is nested somewhere else, and
needs the Node reference.

>>Now, through debugging, I have noticed that the change I made above did
>> not update Jackrabbit's index. Before I try to write up a reproducible
>> test case:
>
>Is that the Lucene index? Or is the property not updated at all?

Yes, the Lucene index. The property is correctly updated. But I forgot to
mention that I've been tampering with the aggregate rules, so it may well
be that I did something wrong in that area.

Further debugging showed that the change set was not assessed "eligible"
for index updates by o.a.j.core.query.lucene.SearchIndex. I guess I broke
something in that area...

>
>> 1. Is this a known issue?
>> 2. Am I misusing API (e.g. session.save())?
>
>See above, I think it's fine.

OK, thanks for your feedback!

Cheers
Lukas

>
>Robert
>
>>
>> I've noticed that Sling's PostOperation uses ResourceResolver.commit(),
>> although that doesn't seem to make the difference.
>>
>> Cheers
>> Lukas
>>

Re: Session.save() and Observation listeners in a SlingAllMethodsServlet

[Robert Munteanu <ro...@apache.org>]

>     @Override
>     protected void doPost(
>         SlingHttpServletRequest request,
>         SlingHttpServletResponse response
>     ) throws ServletException, IOException {
>
>         // [...]
>         Resource resource = request.getResource();
>         Node node = resource.adaptTo(Node.class);
>         node.setProperty("x", "y");
>         node.getSession().save();
>         // [...]
>
>     }


The code looks fine to me, although I'd advise just using the Resource
API if possible, since you already have the resource at hand.

>
> Now, through debugging, I have noticed that the change I made above did
> not update Jackrabbit's index. Before I try to write up a reproducible
> test case:

Is that the Lucene index? Or is the property not updated at all?

> 1. Is this a known issue?
> 2. Am I misusing API (e.g. session.save())?

See above, I think it's fine.

Robert

>
> I've noticed that Sling's PostOperation uses ResourceResolver.commit(),
> although that doesn't seem to make the difference.
>
> Cheers
> Lukas
>