On 11/08/15 18:22, "Julian Reschke" wrote: >On 2015-08-11 14:55, [email protected] 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
