Re: svn commit: r1796624 - /jackrabbit/oak/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/state/AbstractNodeState.java

[Chetan Mehrotra]

On Mon, May 29, 2017 at 6:50 PM,   wrote:
> +private static final int CHILDREN_CAP = getInteger("children.cap", 100);

Better to have system property prefix with 'oak' i.e. 'oak.children.cap'

Chetan Mehrotra

Re: failure building oak-upgrade

[Tomek Rekawek]

Hi,

regression fixed, sorry for that.

Regards,
Tomek

-- 
Tomek Rękawek | Adobe Research | www.adobe.com
reka...@adobe.com

> On 29 May 2017, at 20:11, Vikas Saurabh  wrote:
> 
> Hi Angela,
> 
>> do others experience the same issue? and if yes, is anybody working on
>> this?
>> 
> Yes, this seems to affecting generally (OAK-6273). I guess Tomek would
> check it out.
> 
> Thanks,
> Vikas



smime.p7s
Description: S/MIME cryptographic signature

Re: failure building oak-upgrade

[Vikas Saurabh]

Hi Angela,

> do others experience the same issue? and if yes, is anybody working on
> this?
>
Yes, this seems to affecting generally (OAK-6273). I guess Tomek would
check it out.

Thanks,
Vikas

BUILD FAILURE: Jackrabbit Oak - Build # 353 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #353)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/353/ to 
view the results.

Changes:
[angela] OAK-5882 : Improve coverage for oak.security code in oak-core (wip)

 

Test results:
3 tests failed.
FAILED:  
org.apache.jackrabbit.oak.upgrade.nodestate.FilteringNodeStateTest.shouldHaveCorrectChildOrderProperty

Error Message:
expected:<[football]> but was:<[foo, football]>

Stack Trace:
java.lang.AssertionError: expected:<[football]> but was:<[foo, football]>
at 
org.apache.jackrabbit.oak.upgrade.nodestate.FilteringNodeStateTest.shouldHaveCorrectChildOrderProperty(FilteringNodeStateTest.java:145)


FAILED:  
org.apache.jackrabbit.oak.upgrade.nodestate.report.PeriodicReporterTest.callbackEveryTenProperties

Error Message:

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<10L>->"/counter/10"]
 but: was 

Stack Trace:
java.lang.AssertionError: 

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<10L>->"/counter/10"]
 but: was 
at 
org.apache.jackrabbit.oak.upgrade.nodestate.report.PeriodicReporterTest.callbackEveryTenProperties(PeriodicReporterTest.java:64)


FAILED:  
org.apache.jackrabbit.oak.upgrade.nodestate.report.ReportingNodeStateTest.getPropertyReportsProperty

Error Message:

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<1L>->"/meaningOfLife"]
 but: was 

Stack Trace:
java.lang.AssertionError: 

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<1L>->"/meaningOfLife"]
 but: was 
at 
org.apache.jackrabbit.oak.upgrade.nodestate.report.ReportingNodeStateTest.getPropertyReportsProperty(ReportingNodeStateTest.java:96)

BUILD FAILURE: Jackrabbit Oak - Build # 352 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #352)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/352/ to 
view the results.

Changes:
[tomekr] OAK-6240: Sidegrade support for DocumentNodeStore to Secondary 
NodeStore

Optimize performance for the AbstractDecoratedNodeState#getProperty().
Don't enable the report wrapper for the previous root.

[catholicon] OAK-2808: Active deletion of 'deleted' Lucene index files from 
DataStore without relying on full scale Blob GC

Posix perms don't work on windows. Ignoring inaccessibleWorkDirGivesNoop test 
for windows

 

Test results:
3 tests failed.
FAILED:  
org.apache.jackrabbit.oak.upgrade.nodestate.FilteringNodeStateTest.shouldHaveCorrectChildOrderProperty

Error Message:
expected:<[football]> but was:<[foo, football]>

Stack Trace:
java.lang.AssertionError: expected:<[football]> but was:<[foo, football]>
at 
org.apache.jackrabbit.oak.upgrade.nodestate.FilteringNodeStateTest.shouldHaveCorrectChildOrderProperty(FilteringNodeStateTest.java:145)


FAILED:  
org.apache.jackrabbit.oak.upgrade.nodestate.report.PeriodicReporterTest.callbackEveryTenProperties

Error Message:

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<10L>->"/counter/10"]
 but: was 

Stack Trace:
java.lang.AssertionError: 

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<10L>->"/counter/10"]
 but: was 
at 
org.apache.jackrabbit.oak.upgrade.nodestate.report.PeriodicReporterTest.callbackEveryTenProperties(PeriodicReporterTest.java:64)


FAILED:  
org.apache.jackrabbit.oak.upgrade.nodestate.report.ReportingNodeStateTest.getPropertyReportsProperty

Error Message:

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<1L>->"/meaningOfLife"]
 but: was 

Stack Trace:
java.lang.AssertionError: 

Expected: Reported{ nodes: (map containing [an instance of java.lang.Long->an 
instance of java.lang.String] or ANYTHING), properties: map containing 
[<1L>->"/meaningOfLife"]
 but: was 
at 
org.apache.jackrabbit.oak.upgrade.nodestate.report.ReportingNodeStateTest.getPropertyReportsProperty(ReportingNodeStateTest.java:96)

BUILD FAILURE: Jackrabbit Oak - Build # 351 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #351)

Status: Failure

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/351/ to 
view the results.

Changes:
[mduerig] OAK-6272: AbstractNodeState.toString does not scale to many child 
nodes
Limit the number of child nodes dumped in toString

 

Test results:
All tests passed

Re: codahale metrics Jmx reporter

[Ian Boston]

Hi,
Here are some reporters that work with Sling/Oak/AEM. [1]. They all look
for components registered as implementing MetricsRegistry and then
aggregate the data pumping it out to a reporter. They are all implemented
as independent bundles. TBH I would avoid pumping the metrics into
JMX as JMX was designed for management, and not metrics. It might be able
to cope with trivial metrics sets, but will likely start to consume
unreasonable JVM resources with a production set of metrics..

Most of the reporters in [1] are simple wrappers round other 3rd party
Metrics reporters. If you have a target not included in that list, its
trivial to follow the same pattern.

HTH
Best Regards
Ian

1
https://github.com/ieb/statsd-reporter-osgi
https://github.com/ieb/prometheus-reporter-osgi
https://github.com/ieb/influxdb-reporter-osgi
https://github.com/ieb/gmond-osgi
https://github.com/ieb/tsdb-reporter-osgi

On 29 May 2017 at 12:48, Andrei Kalfas  wrote:

> Hi,
>
> > By default this is the only mode.
>
> What would you guys rather prefer, have a different component peeks into
> the metrics registry or change oak-core to deal with multiple reporters -
> Jmx should be the default one.
>
> Thanks,
> Andrei
>
>

Re: codahale metrics Jmx reporter

[Chetan Mehrotra]

On Mon, May 29, 2017 at 5:18 PM, Andrei Kalfas
 wrote:
> have a different component peeks into the metrics registry or change oak-core 
> to deal with multiple reporters

I would prefer to let Oak focus on basic reporting and some other
component deal with integration with different types of reporters

Chetan Mehrotra

Re: codahale metrics Jmx reporter

[Andrei Kalfas]

Hi,

> By default this is the only mode. 

What would you guys rather prefer, have a different component peeks into the 
metrics registry or change oak-core to deal with multiple reporters - Jmx 
should be the default one.

Thanks,
Andrei



smime.p7s
Description: S/MIME cryptographic signature

Re: codahale metrics Jmx reporter

[Chetan Mehrotra]

On Mon, May 29, 2017 at 5:02 PM, Andrei Kalfas
 wrote:
> Is this the only intended way of reporting these metrics?

By default this is the only mode. In addition the MetricRegistry is
registered in OSGi service registry. So some other component can look
it up and use it with different reporter. This is used in Sling to
report the metrics to Felix WebConsole [1] and [2]

Chetan Mehrotra

[1] 
https://github.com/apache/sling/blob/trunk/bundles/commons/metrics/src/main/java/org/apache/sling/commons/metrics/internal/MetricWebConsolePlugin.java#L106
[2] 
https://sling.apache.org/documentation/bundles/metrics.html#webconsole-plugin

Re: Intent to backport OAK-5934/OAK-5935

[Julian Reschke]

On 2017-05-29 11:32, Amit Jain wrote:

Hi,

I would like to backport OAK-5934/5935 to 1.6. These are performance
optimizations where the downloaded binary is loaded through the cache so
that the cache itself is also populated.

Thanks
Amit


+1

Intent to backport OAK-5934/OAK-5935

[Amit Jain]

Hi,

I would like to backport OAK-5934/5935 to 1.6. These are performance
optimizations where the downloaded binary is loaded through the cache so
that the cache itself is also populated.

Thanks
Amit

copy on write node store

[Tomek Rekawek]

Hello,

in the OAK-6220 I’m exploring a topic of having a switchable copy-on-write node 
store implementation. The idea is that the “main” node store (eg. DocumentMK) 
is wrapped with an extra layer (copy-on-write node store), which can be turned 
on/off in the runtime. When the copy-on-write is turned on, all the new changes 
are not merged with the main store, but kept in a separate, volatile store.

The new mode is meant to be used for testing - so we can perform even 
destructible tests and then reverse all the changes seamlessly. It’s especially 
useful in the blue-green deployments with CompositeNodeStore and DocumentMK, 
since we can test the new version of the application on the new (green) 
instance, even if the tests requires changes in the node schema. The changes 
won’t be propagated to the old (blue) instance as long as the COW mode is on.

Together with other people involved in the issue we had 3 ideas how this can be 
implemented:

1. By copying the / node and its subtree into some private location and then 
mount the COW store on top of it.

This works fine for the SegmentMK (supporting the copy-by-reference), but not 
with the DocumentMK (which actually copied the whole tree). Since the new 
feature is more useful with DocumentMK, we needed to find something else.

2. By storing the data in a NodeBuilder taken from the store without merging it 
back to the main repository.

This seemed to worked fine, but because of the DocumentMK limitations 
(OAK-1838) this wasn’t reliable.

3. By creating a MemoryNodeStore on a top of the recent root state

This is the current implementation, it works fine [1]. The newly created 
MemoryNodeStore didn’t contain any checkpoints, so some extra layer 
(BranchNodeStore) was introduced to inherit the already existing checkpoints 
from the main store. Another layer (CowNodeStore) is being used to dynamically 
switch between the main and the branch node store.

Potential limitation here is that the changes have to fit into memory. 
Switching the repository into COW mode and forgetting about this is not a good 
idea.

I’d like to merge the [1], so the blue-green Sling deployments can be tested in 
the more robust way. Any thoughts?

Regards,
Tomek

[1] https://issues.apache.org/jira/secure/attachment/12868273/OAK-6220-3.patch

-- 
Tomek Rękawek | Adobe Research | www.adobe.com
reka...@adobe.com



smime.p7s
Description: S/MIME cryptographic signature