You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2015/08/11 18:22:42 UTC

Re: svn commit: r1695297 [1/3] - in /jackrabbit/oak/branches/1.0: ./ oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/sort/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugi...

On 2015-08-11 14:55, mreutegg@apache.org wrote:
> Author: mreutegg
> Date: Tue Aug 11 12:55:41 2015
> New Revision: 1695297
>
> URL: http://svn.apache.org/r1695297
> Log:
> OAK-2829: Comparing node states for external changes is too slow
> OAK-3002: Optimize docCache and docChildrenCache invalidation by filtering using journal
>
> Merged revisions 1678023,1678171,1684820,1685590,1685964,1685977,1685989,1686023,1686032,1688179 from trunk
> ...

In general I'm +1000 on making 1.0 as similar to 1.2 as possible.

In this case however I'm a bit concerned about the timing: this would go 
into Oak 1.0.19 which is also supposed to fix a critical bug that we 
introduced in 1.0.16 (https://issues.apache.org/jira/browse/OAK-3169). 
Is it wise to push this rather large change into a release that people 
running 1.0.16...18 simply *have* to switch to ASAP?

Best regards, Julian

Re: svn commit: r1695297 [1/3] - in /jackrabbit/oak/branches/1.0: ./ oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/sort/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/ oak-core/src/main/java/org/apache/jackrabbit/oak/p...

Posted by Marcel Reutegger <mr...@adobe.com>.
On 11/08/15 18:22, "Julian Reschke" wrote:
>On 2015-08-11 14:55, mreutegg@apache.org wrote:
>> Author: mreutegg
>> Date: Tue Aug 11 12:55:41 2015
>> New Revision: 1695297
>>
>> URL: http://svn.apache.org/r1695297
>> Log:
>> OAK-2829: Comparing node states for external changes is too slow
>> OAK-3002: Optimize docCache and docChildrenCache invalidation by
>>filtering using journal
>>
>> Merged revisions
>>1678023,1678171,1684820,1685590,1685964,1685977,1685989,1686023,1686032,1
>>688179 from trunk
>> ...
>
>In general I'm +1000 on making 1.0 as similar to 1.2 as possible.
>
>In this case however I'm a bit concerned about the timing: this would go
>into Oak 1.0.19 which is also supposed to fix a critical bug that we
>introduced in 1.0.16 (https://issues.apache.org/jira/browse/OAK-3169).
>Is it wise to push this rather large change into a release that people
>running 1.0.16...18 simply *have* to switch to ASAP?

I share your concern, but OAK-2829 is critical as well for clustered
deployments. Without OAK-2829 chances are quite high that an observation
queue fills up at some point and events are delayed for a very long time.
All tests so far look fine and we still have time to perform additional
tests until we release 1.0.19 to identify any regressions.

I think this shows the downside of a rather monolithic core artifact we
currently have. See also the modularization discussion we recently had.
If the DocumentNodeStore was in a separate module, users could e.g. pull
in the fix for OAK-3169 ASAP but delay OAK-2829.

Regards
 Marcel

Re: svn commit: r1695297 [1/3] - in /jackrabbit/oak/branches/1.0: ./ oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/sort/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugi...

Posted by Michael Dürig <md...@apache.org>.

On 11.8.15 6:22 , Julian Reschke wrote:
> On 2015-08-11 14:55, mreutegg@apache.org wrote:
>> Author: mreutegg
>> Date: Tue Aug 11 12:55:41 2015
>> New Revision: 1695297
>>
>> URL: http://svn.apache.org/r1695297
>> Log:
>> OAK-2829: Comparing node states for external changes is too slow
>> OAK-3002: Optimize docCache and docChildrenCache invalidation by
>> filtering using journal
>>
>> Merged revisions
>> 1678023,1678171,1684820,1685590,1685964,1685977,1685989,1686023,1686032,1688179
>> from trunk
>> ...
>
> In general I'm +1000 on making 1.0 as similar to 1.2 as possible.
>
> In this case however I'm a bit concerned about the timing: this would go
> into Oak 1.0.19 which is also supposed to fix a critical bug that we
> introduced in 1.0.16 (https://issues.apache.org/jira/browse/OAK-3169).
> Is it wise to push this rather large change into a release that people
> running 1.0.16...18 simply *have* to switch to ASAP?

That's right the point I'm trying to bring across in the modularisation 
discussion: if we had proper modules such a change wouldn't impact not 
affected customers.

Michael

>
> Best regards, Julian