> On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote:
>>>
>>>
>>>
>>> On 21.9.16 9:14 , Carsten Ziegeler wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 21.9.16 8:50 , Carsten Ziegeler wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 21.9.16 8:33 , Carsten Ziegeler wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pushing filters as much into Oak has many performance
>>>>>>>>> advantages
>>>>>>>>> though
>>>>>>>>>>
>>>>>>>>>> compared to filter messages after delivery. Also Oak
>>>>>>>>>> would easily
>>>>>>>>>> able
>>>>>>>>>> to support the delete use case described above.
>>>>>>>>>>
>>>>>>>> In all cases, always, guaranteed?
>>>>>>>
>>>>>>> For some definition of "all cases, always, guaranteed": yes
>>>>>>> ;-)
>>>>>>
>>>>>> :) So there is no compaction, never?
>>>>>
>>>>> There isn't if you configure it that way. It's up to you.
>>>>>
>>>>> But this is completely irrelevant here. If compaction would
>>>>> cause events
>>>>> to get lost, there is nothing you could do about it in Sling.
>>>>> Regardless
>>>>> whether you implement an ad-hoc DYI filter in Sling or use Oak
>>>>> filters.
>>>>>
>>>> I agree.
>>>>
>>>> Just to clarify, if I delete "/libs/foo" I get oak observation
>>>> events
>>>> for all nodes that where under /foo with the removed properties
>>>> of each
>>>> node, right?
>>>
>>> No, just for the root of the removed tree.
>>>
>>> See
>>> https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=139
>>> 11484&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel#comment-13911484
>>>
>>>
>> ah..memories :)
>>
>> ok, but that proves my point that glob filtering does not work for
>> remove
> 
> Is that a hard blocker? I can imagine that it's more convenient for the
> application to get discrete change events for each removal, but if we
> slightly change the contract to follow Oak's approach, would it be more
> performant?
> 
> Without looking in more detail, I would imagine that the application
> usually needs to clear caches or stop doing work when such an instance
> is removed. The application can then do this for all resources with a
> common parent. Sure, it's slightly more verbose and might require a
> slight rearrangement of in-memory data structures, but overall doable.

It's not a problem in general - the problem is that we don't specify the
behaviour correctly. Right now code registering a listener with a glob
pattern of **.jsp expects to get remove events in all case for exactly
the removed jsps. But this is only true if the jsp is directly removed,
not if any parent is removed.

So we a) need to clarify the contract and b) think about what we do if
someone registers for a glob pattern. Do we send removal of parents
automatically or do we expect to listener to register at /?

Regards
Carsten
> 
> Stefan also echoed the same concern - sometimes it's not possible ( or
> performant/scalable ) to have such fine-grained change notifications.
> 
> Robert
> 
>>
>> Carsten
>>
>>>
>>> ;-)
>>>
>>> Michael
>>>
>>>>
>>>>
>>>> Carsten
>>>>
>>>>
>>>>
>>>
>>
>>
>>  
>>
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Reply via email to