date:20140227


[ 
https://issues.apache.org/jira/browse/OAK-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914205#comment-13914205
 ] 

Michael Dürig commented on OAK-453:
---

I would like to wait for the outcome of the workspace discussion and follow up 
from there. I still think {{Root.move()}} looks alien and it should be 
{{Tree.moveTo()}}.

 Move move and copy methods from Root to Tree
 

 Key: OAK-453
 URL: https://issues.apache.org/jira/browse/OAK-453
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: Michael Dürig
Priority: Minor
 Fix For: 1.0

 Attachments: OAK-453.patch


 In OAK-391 we decided to not track trees through moves any more (see also 
 http://markmail.org/message/b6dcyae362akyogd). This allows us to move the 
 {{move}} and {{copy}} methods from {{Root}} to {{Tree}} where they feel more 
 natural. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (OAK-1267) Failure in ObservationRefreshTest


 [ 
https://issues.apache.org/jira/browse/OAK-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1267:


Assignee: Michael Dürig  (was: Tobias Bocanegra)

 Failure in ObservationRefreshTest 
 --

 Key: OAK-1267
 URL: https://issues.apache.org/jira/browse/OAK-1267
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Michael Dürig
 Fix For: 0.18


 Failed tests:   
 observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest):
  added nodes expected:1000 but was:442
 Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 106.957 sec 
  FAILURE!
 observation[3](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest)
   Time elapsed: 53.047 sec   FAILURE!
 java.lang.AssertionError: added nodes expected:1000 but was:906
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at 
 org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
   at org.junit.runners.Suite.runChild(Suite.java:128)
   at org.junit.runners.Suite.runChild(Suite.java:24)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:695)
 observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest)
   Time elapsed: 58.379 sec   FAILURE!
 java.lang.AssertionError: added nodes expected:1000 but was:396
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at 
 org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
   at

[jira] [Commented] (OAK-1267) Failure in ObservationRefreshTest


[ 
https://issues.apache.org/jira/browse/OAK-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914211#comment-13914211
 ] 

angela commented on OAK-1267:
-

[~mduerig] since this is observation related, would it be something you could 
take a look at?

 Failure in ObservationRefreshTest 
 --

 Key: OAK-1267
 URL: https://issues.apache.org/jira/browse/OAK-1267
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Michael Dürig
 Fix For: 0.18


 Failed tests:   
 observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest):
  added nodes expected:1000 but was:442
 Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 106.957 sec 
  FAILURE!
 observation[3](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest)
   Time elapsed: 53.047 sec   FAILURE!
 java.lang.AssertionError: added nodes expected:1000 but was:906
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at 
 org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
   at org.junit.runners.Suite.runChild(Suite.java:128)
   at org.junit.runners.Suite.runChild(Suite.java:24)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:695)
 observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest)
   Time elapsed: 58.379 sec   FAILURE!
 java.lang.AssertionError: added nodes expected:1000 but was:396
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at 
 org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at

[jira] [Created] (OAK-1476) Hardcoded SecurityProvider implementation in oak-jcr Activator

angela created OAK-1476:
---

 Summary: Hardcoded SecurityProvider implementation in oak-jcr 
Activator
 Key: OAK-1476
 URL: https://issues.apache.org/jira/browse/OAK-1476
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Jukka Zitting
 Fix For: 0.19


the Activator in o.a.j.oak.jcr.jcr.osgi contains a hardcoded reference to the 
SecurityProviderImpl. This is obviously not the desired outcome of making the 
security part pluggable at runtime.

[~jukkaz], since you are the author of the Activator, could you take a look at 
this again? 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1476) Hardcoded SecurityProvider implementation in oak-jcr Activator


[ 
https://issues.apache.org/jira/browse/OAK-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914232#comment-13914232
 ] 

angela commented on OAK-1476:
-

in addition the buildSecurityConfig method add some adobe specific default 
values for the user mgt setup. what's the intention behind this?

 Hardcoded SecurityProvider implementation in oak-jcr Activator
 --

 Key: OAK-1476
 URL: https://issues.apache.org/jira/browse/OAK-1476
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Jukka Zitting
 Fix For: 0.19


 the Activator in o.a.j.oak.jcr.jcr.osgi contains a hardcoded reference to the 
 SecurityProviderImpl. This is obviously not the desired outcome of making the 
 security part pluggable at runtime.
 [~jukkaz], since you are the author of the Activator, could you take a look 
 at this again? 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Reopened] (OAK-162) Oak Layering / Remoting architecture

2014-02-27 Thread Stefan Guggisberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Guggisberg reopened OAK-162:
---


sorry, i  don't agree with the resolution.

 Oak Layering / Remoting architecture
 

 Key: OAK-162
 URL: https://issues.apache.org/jira/browse/OAK-162
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Stefan Guggisberg

 i had the impression that we started the oak project with a shared view of 
 the layering architecture (roughly based on the jackrabbit spi 
 abstraction/partitioning model).
 the jcr api already implies 2 layers (client/server):
 - session-related operations (transient space etc) 
   - javax.jcr.Session
 - workspace-related operations (versioning, locking, node types etc) 
   - javax.jcr.Workspace
 the jackrabbit spi represents the abstraction of the workspace-related 
 functionality and obviously lends itself to be remoted.
 here's my understanding of how the oak layering model should look like:
 1. jcr client (oak-jcr):
exposes the jcr api and implements the session-related functionality
(transient space!); delegates workspace-related operations to the 
spi (oak api)
 2. server-side repository (oak-core): exposes the spi (oak api) and 
implements the workspace-related operations; delegates 
persistence-related operations to the mk (oak api)
 3. persistence layer (oak-mk): exposes the mk api and implements
persistence operations
 the oak api and the mk api are the obvious potential remoting points.
 i see the following issues with the current oak code base:
 - the 3 layers are not properly isolated, transient space operations
   e.g. reach through all 3 layers. workspace mgmt e.g. is 
   handled on the client. if either the oak or the mk api is
   remoted this is serious potential performance problem.  
 - there's a mismatch between the spi and the current oak api
   in terms of scope/functionality; several workspace operations 
   (such as versioning, ns mgmt, node type mgmt) don't seem to 
   be reflected in the oak api.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1397) VersionHistory#removeVersion

2014-02-27 Thread Alex Parvulescu (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914248#comment-13914248
 ] 

Alex Parvulescu commented on OAK-1397:
--

I fixed the ReferenceEditor issue with rev http://svn.apache.org/r1572477

It was indeed an issue with the _discardedIds_ set, I think the issue came from 
the fact that you had the same uuid involved in a normal reference removal but 
also something related to the version store, and the code couldn't cope with 
that.

I'll also apply the original patch shortly.

 VersionHistory#removeVersion
 

 Key: OAK-1397
 URL: https://issues.apache.org/jira/browse/OAK-1397
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela
Assignee: Alex Parvulescu
 Fix For: 0.18

 Attachments: OAK-1397.patch, OAK-1397_initial_work.patch, 
 RemoveVersionTest-jackrabbit-core.patch






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (OAK-1477) ObservationRefreshTest very slow for DOCUMENT_JDBC fixture

Michael Dürig created OAK-1477:
--

 Summary: ObservationRefreshTest very slow for DOCUMENT_JDBC fixture
 Key: OAK-1477
 URL: https://issues.apache.org/jira/browse/OAK-1477
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mk
Reporter: Michael Dürig


AFAICS the slowness is due to many subsequent calls to {{Session.save}}, which 
seem to be slow. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (OAK-1397) VersionHistory#removeVersion

2014-02-27 Thread Alex Parvulescu (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Parvulescu resolved OAK-1397.
--

Resolution: Fixed

fixed with rev http://svn.apache.org/r1572485

Thanks Marcel for the help investigating the reference editor issue! 

 VersionHistory#removeVersion
 

 Key: OAK-1397
 URL: https://issues.apache.org/jira/browse/OAK-1397
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela
Assignee: Alex Parvulescu
 Fix For: 0.18

 Attachments: OAK-1397.patch, OAK-1397_initial_work.patch, 
 RemoveVersionTest-jackrabbit-core.patch






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1267) Failure in ObservationRefreshTest


[ 
https://issues.apache.org/jira/browse/OAK-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914342#comment-13914342
 ] 

Michael Dürig commented on OAK-1267:


At http://svn.apache.org/r1572492 I disabled the test for the JDBC fixture. See 
OAK-1477. I also tweaked the test setup a bit such that the various fixtures do 
not run in parallel any more. I have the impression the issue is caused by a 
resource quench causing some of the fixtures to simply time out. Let's see what 
the CI says. 

 Failure in ObservationRefreshTest 
 --

 Key: OAK-1267
 URL: https://issues.apache.org/jira/browse/OAK-1267
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: Michael Dürig
 Fix For: 0.18


 Failed tests:   
 observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest):
  added nodes expected:1000 but was:442
 Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 106.957 sec 
  FAILURE!
 observation[3](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest)
   Time elapsed: 53.047 sec   FAILURE!
 java.lang.AssertionError: added nodes expected:1000 but was:906
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at 
 org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
   at org.junit.runners.Suite.runChild(Suite.java:128)
   at org.junit.runners.Suite.runChild(Suite.java:24)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:695)
 observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest)
   Time elapsed: 58.379 sec   FAILURE!
 java.lang.AssertionError: added nodes expected:1000 but was:396
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at 
 org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at

[jira] [Updated] (OAK-1477) ObservationRefreshTest very slow for DOCUMENT_JDBC fixture


 [ 
https://issues.apache.org/jira/browse/OAK-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig updated OAK-1477:
---

Assignee: Julian Reschke

 ObservationRefreshTest very slow for DOCUMENT_JDBC fixture
 --

 Key: OAK-1477
 URL: https://issues.apache.org/jira/browse/OAK-1477
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mk
Reporter: Michael Dürig
Assignee: Julian Reschke

 AFAICS the slowness is due to many subsequent calls to {{Session.save}}, 
 which seem to be slow. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (OAK-1325) Support native pass-through queries (e.g. Lucene)


 [ 
https://issues.apache.org/jira/browse/OAK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller updated OAK-1325:


Fix Version/s: 0.18

 Support native pass-through queries (e.g. Lucene)
 -

 Key: OAK-1325
 URL: https://issues.apache.org/jira/browse/OAK-1325
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: oak-lucene, oak-solr, query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
 Fix For: 0.18

 Attachments: OAK-1325.1.patch, OAK-1325.patch


 The query engine currently supports XPath and SQL-2 queries as documented by 
 the JCR 2.0 specification. Some queries require syntax that goes beyond the 
 JCR 2.0 spec, even thought the feature is supported by the query index. One 
 example is MoreLikeThis in OAK-1286.
 We would like an extension point so that a user of Oak can use the feature of 
 the query index. There are multiple options:
 * Use a separate, custom query language (not XPath or SQL-2)
 * Extend the XPath and/or SQL-2 syntax similar to rep:excerpt()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (OAK-1325) Support native pass-through queries (e.g. Lucene)


 [ 
https://issues.apache.org/jira/browse/OAK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller reassigned OAK-1325:
---

Assignee: Thomas Mueller

 Support native pass-through queries (e.g. Lucene)
 -

 Key: OAK-1325
 URL: https://issues.apache.org/jira/browse/OAK-1325
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: oak-lucene, oak-solr, query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
 Fix For: 0.18

 Attachments: OAK-1325.1.patch, OAK-1325.patch


 The query engine currently supports XPath and SQL-2 queries as documented by 
 the JCR 2.0 specification. Some queries require syntax that goes beyond the 
 JCR 2.0 spec, even thought the feature is supported by the query index. One 
 example is MoreLikeThis in OAK-1286.
 We would like an extension point so that a user of Oak can use the feature of 
 the query index. There are multiple options:
 * Use a separate, custom query language (not XPath or SQL-2)
 * Extend the XPath and/or SQL-2 syntax similar to rep:excerpt()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1472) ConcurrentAddReferenceTest#addReferences still fails

2014-02-27 Thread Alex Parvulescu (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914350#comment-13914350
 ] 

Alex Parvulescu commented on OAK-1472:
--

is this test still failing? for me it looks good locally.

 ConcurrentAddReferenceTest#addReferences still fails
 

 Key: OAK-1472
 URL: https://issues.apache.org/jira/browse/OAK-1472
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela
 Fix For: 0.19


 the test ConcurrentAddReferenceTest#addReferences is marked with @Ignore 
 pointing to OAK-1137 which has been resolved already for release 0.12.
 Opening a new issue here in order to keep track of the failing test and get a 
 resolution for this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (OAK-1286) Enable/expose MoreLikeThis queries


 [ 
https://issues.apache.org/jira/browse/OAK-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved OAK-1286.
-

Resolution: Fixed

 Enable/expose MoreLikeThis queries
 --

 Key: OAK-1286
 URL: https://issues.apache.org/jira/browse/OAK-1286
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: oak-lucene
Reporter: Laurie byrum
Assignee: Thomas Mueller
 Fix For: 0.18


 The software I'm building currently makes use of Lucene's MoreLikeThis \[1\] 
 facilities in order to match user's search with Nodes in a JCR repository. 
 MoreLikeThis gives us much better results than, for example, simple full text 
 search.
 We have currently implemented this by having our own Lucene indices. For 
 simplicity and efficiency, we'd prefer to use the copy of Lucene that is 
 already built into Oak. To do so, I think we would need to add an indexer 
 config. We would also need a way to pass such queries through the jcr query 
 api. We would need something very similar to rep:similar, but we would want 
 to be able to pass the similar text through the api (I believe the current 
 rep:similar can only take a node to be matched, as opposed to text to be 
 matched).
 \[1\] 
 http://lucene.apache.org/core/3_0_3/api/contrib-queries/org/apache/lucene/search/similar/MoreLikeThis.html



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1286) Enable/expose MoreLikeThis queries

[
https://issues.apache.org/jira/browse/OAK-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914408#comment-13914408
]

Thomas Mueller commented on OAK-1286:
-

We decided to solve the more generic use case native queries (OAK-1325),
which is now implemented.

When using the Solr index, MoreLikeThis queries can now be executed as
described in the [Oak query
documentation|http://jackrabbit.apache.org/oak/docs/query.html#Native_Queries].

[~teofili] told me he would like to make the MoreLikeThis feature also
available for Apache Lucene (not just Solr), but this will require some more
changes.

Enable/expose MoreLikeThis queries
--

Key: OAK-1286
URL: https://issues.apache.org/jira/browse/OAK-1286
Project: Jackrabbit Oak
Issue Type: Improvement
Components: oak-lucene
Reporter: Laurie byrum
Assignee: Thomas Mueller
Fix For: 0.18

The software I'm building currently makes use of Lucene's MoreLikeThis \[1\]
facilities in order to match user's search with Nodes in a JCR repository.
MoreLikeThis gives us much better results than, for example, simple full text
search.
We have currently implemented this by having our own Lucene indices. For
simplicity and efficiency, we'd prefer to use the copy of Lucene that is
already built into Oak. To do so, I think we would need to add an indexer
config. We would also need a way to pass such queries through the jcr query
api. We would need something very similar to rep:similar, but we would want
to be able to pass the similar text through the api (I believe the current
rep:similar can only take a node to be matched, as opposed to text to be
matched).
\[1\]
http://lucene.apache.org/core/3_0_3/api/contrib-queries/org/apache/lucene/search/similar/MoreLikeThis.html

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1325) Support native pass-through queries (e.g. Lucene)


[ 
https://issues.apache.org/jira/browse/OAK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914469#comment-13914469
 ] 

Thomas Mueller commented on OAK-1325:
-

By the way, the internal property name is native\*type (for example 
native\*lucene or native\*solr).

 Support native pass-through queries (e.g. Lucene)
 -

 Key: OAK-1325
 URL: https://issues.apache.org/jira/browse/OAK-1325
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: oak-lucene, oak-solr, query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
 Fix For: 0.18

 Attachments: OAK-1325.1.patch, OAK-1325.patch


 The query engine currently supports XPath and SQL-2 queries as documented by 
 the JCR 2.0 specification. Some queries require syntax that goes beyond the 
 JCR 2.0 spec, even thought the feature is supported by the query index. One 
 example is MoreLikeThis in OAK-1286.
 We would like an extension point so that a user of Oak can use the feature of 
 the query index. There are multiple options:
 * Use a separate, custom query language (not XPath or SQL-2)
 * Extend the XPath and/or SQL-2 syntax similar to rep:excerpt()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1477) ObservationRefreshTest very slow for DOCUMENT_JDBC fixture

2014-02-27 Thread Julian Reschke (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914542#comment-13914542
 ] 

Julian Reschke commented on OAK-1477:
-

Confirmed. Will investigate slowness.

 ObservationRefreshTest very slow for DOCUMENT_JDBC fixture
 --

 Key: OAK-1477
 URL: https://issues.apache.org/jira/browse/OAK-1477
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mk
Reporter: Michael Dürig
Assignee: Julian Reschke

 AFAICS the slowness is due to many subsequent calls to {{Session.save}}, 
 which seem to be slow. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture

2014-02-27 Thread Stefan Guggisberg (JIRA)

[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914562#comment-13914562
]

Stefan Guggisberg commented on OAK-162:
---

~jukka, i think i've expressed my concerns pretty clearly in this issue.

resolving the issue as 'not a problem', after almost 2 years of silence, is IMO
unacceptable.

bq. This is a concern for the remoting protocol to address.

what remoting protocol?

bq. I don't see a compelling reason why such operations should be explicitly
exposed in the API.

how would a remote jcr client (oak-jcr) access e.g. versioning functionality
provided by oak-core?

Oak Layering / Remoting architecture

Key: OAK-162
URL: https://issues.apache.org/jira/browse/OAK-162
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Stefan Guggisberg

i had the impression that we started the oak project with a shared view of
the layering architecture (roughly based on the jackrabbit spi
abstraction/partitioning model).
the jcr api already implies 2 layers (client/server):
- session-related operations (transient space etc)
- javax.jcr.Session
- workspace-related operations (versioning, locking, node types etc)
- javax.jcr.Workspace
the jackrabbit spi represents the abstraction of the workspace-related
functionality and obviously lends itself to be remoted.
here's my understanding of how the oak layering model should look like:
1. jcr client (oak-jcr):
exposes the jcr api and implements the session-related functionality
(transient space!); delegates workspace-related operations to the
spi (oak api)
2. server-side repository (oak-core): exposes the spi (oak api) and
implements the workspace-related operations; delegates
persistence-related operations to the mk (oak api)
3. persistence layer (oak-mk): exposes the mk api and implements
persistence operations
the oak api and the mk api are the obvious potential remoting points.
i see the following issues with the current oak code base:
- the 3 layers are not properly isolated, transient space operations
e.g. reach through all 3 layers. workspace mgmt e.g. is
handled on the client. if either the oak or the mk api is
remoted this is serious potential performance problem.
- there's a mismatch between the spi and the current oak api
in terms of scope/functionality; several workspace operations
(such as versioning, ns mgmt, node type mgmt) don't seem to
be reflected in the oak api.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture

2014-02-27 Thread Marcel Reutegger (JIRA)

[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914576#comment-13914576
]

Marcel Reutegger commented on OAK-162:
--

bq. how would a remote jcr client (oak-jcr) access e.g. versioning
functionality provided by oak-core?

so far we didn't have this requirement, but in general it works by setting
protected properties on the Oak API level and a commit editor takes care of the
correct version related updates on the version storage. The contract is not
documented yet, but the general idea is described here:
http://markmail.org/message/k7bbvwvf25irn6jt

Oak Layering / Remoting architecture

Key: OAK-162
URL: https://issues.apache.org/jira/browse/OAK-162
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Stefan Guggisberg

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture

2014-02-27 Thread Jukka Zitting (JIRA)

[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914582#comment-13914582
]

Jukka Zitting commented on OAK-162:
---

During those two years we had lots of discussions about these issues on
oak-dev@, and as a result I feel that this is no longer a problem, thus the
resolution. If not a problem, then at least incomplete, as I genuinely don't
know what you want changed and why.

bq. what remoting protocol?

The protocol you refer to in if either the oak or the mk api is remoted, for
example oak-mk-remote.

bq. how would a remote jcr client (oak-jcr) access e.g. versioning
functionality provided by oak-core?

The way it already does. I don't see the problem here, can you elaborate?

Oak Layering / Remoting architecture

Key: OAK-162
URL: https://issues.apache.org/jira/browse/OAK-162
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Stefan Guggisberg

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (OAK-1399) Drop TODO.java again from the oak utils


 [ 
https://issues.apache.org/jira/browse/OAK-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela resolved OAK-1399.
-

   Resolution: Fixed
Fix Version/s: (was: 1.0)
   0.18

removed obsolete import r1572609
removed TODO.java r1572610

 Drop TODO.java again from the oak utils
 ---

 Key: OAK-1399
 URL: https://issues.apache.org/jira/browse/OAK-1399
 Project: Jackrabbit Oak
  Issue Type: Wish
  Components: core
Reporter: angela
Assignee: angela
 Fix For: 0.18

 Attachments: OAK-1399.patch


 as suggested on the mailing list i would like us to get rid of the TODO class 
 again. afaik it's usage is now limited to the versioning code base, where IMO 
 are only 2 blocking issues left:
 - VersionHistory#removeVersion
 - OPV Initialize
 i would suggest to get these 2 fixed as soon as possible and replace the 
 other usages of TODO by UnsupportedRepositoryException and only fix them if 
 we have a compelling reason to do so (all the other fancy features of the JCR 
 versioning)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture

2014-02-27 Thread Stefan Guggisberg (JIRA)

[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914614#comment-13914614
]

Stefan Guggisberg commented on OAK-162:
---

bq. The way it already does.

can you please elaborate? i don't see any versioning related oak-core API
methods. i neither see any remoting protocol exposing equivalent functionality
like batch read, batch write, checkin, copy, move, etc.

Oak Layering / Remoting architecture

Key: OAK-162
URL: https://issues.apache.org/jira/browse/OAK-162
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Stefan Guggisberg

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (OAK-1479) Failing test for MergeSortedIterators


[ 
https://issues.apache.org/jira/browse/OAK-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914650#comment-13914650
 ] 

angela commented on OAK-1479:
-

the test is still marked with @Ignore, although the referenced issue has 
already been resolved.

 Failing test for MergeSortedIterators
 -

 Key: OAK-1479
 URL: https://issues.apache.org/jira/browse/OAK-1479
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mongomk
Affects Versions: 0.12
Reporter: Chetan Mehrotra
Assignee: Marcel Reutegger
  Labels: cluster
 Fix For: 0.18


 While running Oak in a two node clutser following exception is seen. It 
 basically comes because the AsynchUpdate tries to update async-status 
 concurrently
 {noformat}
 27.11.2013 17:56:35.507 *ERROR* [pool-5-thread-1] 
 org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job 
 execution of org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate@fcf98c2 
 : com.google.common.util.concurrent.UncheckedExecutionException: 
 java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
 com.google.common.util.concurrent.UncheckedExecutionException: 
 com.google.common.util.concurrent.UncheckedExecutionException: 
 java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
 ~[na:na]
   at com.google.common.cache.LocalCache.get(LocalCache.java:3932) ~[na:na]
   at 
 com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diff(MongoMK.java:165) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:481)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:103)
  ~[na:na]
   at 
 org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105)
  ~[org.apache.sling.commons.scheduler:2.4.2]
   at org.quartz.core.JobRunShell.run(JobRunShell.java:207) 
 [org.apache.sling.commons.scheduler:2.4.2]
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  [na:1.7.0_40]
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [na:1.7.0_40]
   at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]
 Caused by: com.google.common.util.concurrent.UncheckedExecutionException: 
 java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
 ~[na:na]
   at com.google.common.cache.LocalCache.get(LocalCache.java:3932) ~[na:na]
   at 
 com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.getNode(MongoNodeStore.java:507)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diffFewChildren(MongoMK.java:313)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diffImpl(MongoMK.java:229) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK$1.call(MongoMK.java:168) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK$1.call(MongoMK.java:165) 
 ~[na:na]
   at 
 com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
  ~[na:na]
   at 
 com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
  ~[na:na]
   at 
 com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315) 
 ~[na:na]
   at 
 com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
  ~[na:na]
   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193) 
 ~[na:na]
   ... 11 common frames omitted
 Caused by: java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.util.MergeSortedIterators.fetchNextIterator(MergeSortedIterators.java:103)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.util.MergeSortedIterators.next(MergeSortedIterators.java:85)
  ~[na:na]
   at

[jira] [Updated] (OAK-1479) Failing test for MergeSortedIterators


 [ 
https://issues.apache.org/jira/browse/OAK-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

angela updated OAK-1479:


Fix Version/s: (was: 0.15)
   0.18

 Failing test for MergeSortedIterators
 -

 Key: OAK-1479
 URL: https://issues.apache.org/jira/browse/OAK-1479
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mongomk
Affects Versions: 0.12
Reporter: Chetan Mehrotra
Assignee: Marcel Reutegger
  Labels: cluster
 Fix For: 0.18


 While running Oak in a two node clutser following exception is seen. It 
 basically comes because the AsynchUpdate tries to update async-status 
 concurrently
 {noformat}
 27.11.2013 17:56:35.507 *ERROR* [pool-5-thread-1] 
 org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job 
 execution of org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate@fcf98c2 
 : com.google.common.util.concurrent.UncheckedExecutionException: 
 java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
 com.google.common.util.concurrent.UncheckedExecutionException: 
 com.google.common.util.concurrent.UncheckedExecutionException: 
 java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
 ~[na:na]
   at com.google.common.cache.LocalCache.get(LocalCache.java:3932) ~[na:na]
   at 
 com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diff(MongoMK.java:165) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:481)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:103)
  ~[na:na]
   at 
 org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105)
  ~[org.apache.sling.commons.scheduler:2.4.2]
   at org.quartz.core.JobRunShell.run(JobRunShell.java:207) 
 [org.apache.sling.commons.scheduler:2.4.2]
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  [na:1.7.0_40]
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [na:1.7.0_40]
   at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]
 Caused by: com.google.common.util.concurrent.UncheckedExecutionException: 
 java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
 ~[na:na]
   at com.google.common.cache.LocalCache.get(LocalCache.java:3932) ~[na:na]
   at 
 com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.getNode(MongoNodeStore.java:507)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diffFewChildren(MongoMK.java:313)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diffImpl(MongoMK.java:229) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK$1.call(MongoMK.java:168) 
 ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.MongoMK$1.call(MongoMK.java:165) 
 ~[na:na]
   at 
 com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
  ~[na:na]
   at 
 com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
  ~[na:na]
   at 
 com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315) 
 ~[na:na]
   at 
 com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
  ~[na:na]
   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193) 
 ~[na:na]
   ... 11 common frames omitted
 Caused by: java.lang.IllegalStateException: Revisioned values for property 
 1:/oak:index/async-status: First element of next iterator must be greater 
 than previous iterator
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.util.MergeSortedIterators.fetchNextIterator(MergeSortedIterators.java:103)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.util.MergeSortedIterators.next(MergeSortedIterators.java:85)
  ~[na:na]
   at 
 org.apache.jackrabbit.oak.plugins.mongomk.NodeDocument.getLatestValue(NodeDocument.java:1041)
  ~[na:na]
   at

[jira] [Created] (OAK-1479) Failing test for MergeSortedIterators

angela created OAK-1479:
---

 Summary: Failing test for MergeSortedIterators
 Key: OAK-1479
 URL: https://issues.apache.org/jira/browse/OAK-1479
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mongomk
Affects Versions: 0.12
Reporter: Chetan Mehrotra
Assignee: Marcel Reutegger
 Fix For: 0.15


While running Oak in a two node clutser following exception is seen. It 
basically comes because the AsynchUpdate tries to update async-status 
concurrently

{noformat}
27.11.2013 17:56:35.507 *ERROR* [pool-5-thread-1] 
org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job 
execution of org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate@fcf98c2 : 
com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Revisioned values for property 
1:/oak:index/async-status: First element of next iterator must be greater than 
previous iterator
com.google.common.util.concurrent.UncheckedExecutionException: 
com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Revisioned values for property 
1:/oak:index/async-status: First element of next iterator must be greater than 
previous iterator
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
~[na:na]
at com.google.common.cache.LocalCache.get(LocalCache.java:3932) ~[na:na]
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diff(MongoMK.java:165) 
~[na:na]
at 
org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:481)
 ~[na:na]
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) 
~[na:na]
at 
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:103)
 ~[na:na]
at 
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105)
 ~[org.apache.sling.commons.scheduler:2.4.2]
at org.quartz.core.JobRunShell.run(JobRunShell.java:207) 
[org.apache.sling.commons.scheduler:2.4.2]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
[na:1.7.0_40]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
[na:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]
Caused by: com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Revisioned values for property 
1:/oak:index/async-status: First element of next iterator must be greater than 
previous iterator
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
~[na:na]
at com.google.common.cache.LocalCache.get(LocalCache.java:3932) ~[na:na]
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.getNode(MongoNodeStore.java:507)
 ~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diffFewChildren(MongoMK.java:313)
 ~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoMK.diffImpl(MongoMK.java:229) 
~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoMK$1.call(MongoMK.java:168) 
~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoMK$1.call(MongoMK.java:165) 
~[na:na]
at 
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
 ~[na:na]
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
 ~[na:na]
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315) 
~[na:na]
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
 ~[na:na]
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193) 
~[na:na]
... 11 common frames omitted
Caused by: java.lang.IllegalStateException: Revisioned values for property 
1:/oak:index/async-status: First element of next iterator must be greater than 
previous iterator
at 
org.apache.jackrabbit.oak.plugins.mongomk.util.MergeSortedIterators.fetchNextIterator(MergeSortedIterators.java:103)
 ~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.util.MergeSortedIterators.next(MergeSortedIterators.java:85)
 ~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.NodeDocument.getLatestValue(NodeDocument.java:1041)
 ~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.NodeDocument.getNodeAtRevision(NodeDocument.java:456)
 ~[na:na]
at 
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.readNode(MongoNodeStore.java:653)
 ~[na:na]
at

[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture

[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914713#comment-13914713
]

Michael Dürig commented on OAK-162:
---

bq. resolving the issue as 'not a problem', after almost 2 years of silence, is
IMO unacceptable.

There has been lots of discussions both on the list and on other issues and
thus sufficient opportunities to participate and shape the course and outcome
of Oak. The fact that there was silence on this particular issue does not
matter to that respect. It merely indicates that the scope of the issue was too
broad, too vague or was based on a wrong premise to be directly actionable upon
and that no one pursued it any further. As Jukka mentioned, the overall
architecture has evolved. That process has taken place in the open by the
consensus driven approach common to all Apache projects. Resolving this issue
now is a matter of hygiene while we progress towards our first major release.

Oak Layering / Remoting architecture

Key: OAK-162
URL: https://issues.apache.org/jira/browse/OAK-162
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Stefan Guggisberg

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (OAK-1480) Wrong default value for group-paths in GroupEditor

angela created OAK-1480:
---

 Summary: Wrong default value for group-paths in GroupEditor
 Key: OAK-1480
 URL: https://issues.apache.org/jira/browse/OAK-1480
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: upgrade
Reporter: angela
 Fix For: 0.18


the GroupEditor in the upgrade package defines the following default path for 
the group nodes:

private final static String[] ROOTS = {home, groups};

1. this doesn't correspond to the default value defined in oak
2. this should obviously be retrieved from the user configuration.





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (OAK-1480) Wrong default value for group-paths in GroupEditor