Failed tests:
testConcurrenCreateOrUpdate[2](org.apache.jackrabbit.oak.plugins.document.ConcurrentDocumentStoreTest):
org.apache.jackrabbit.mk.api.MicroKernelException:
org.h2.jdbc.JdbcSQLException: Unique index or primary key violation:
PRIMARY_KEY_47 ON PUBLIC.NODES(ID) VALUES ( /* 2 */
Build Update for apache/jackrabbit-oak
-
Build: #4052
Status: Fixed
Duration: 2731 seconds
Commit: 47b339c2942b8a195a5baff4da80863f8645d8df (trunk)
Author: Michael Duerig
Message: OAK-1414: Copying a large subtrees does not scale as expected in the
number of
Hi,
The vote passes as follows (* marks a binding vote):
+1 Alex Parvulescu *
+1 Davide Giannella
+1 Julian Reschke *
+1 Marcel Reutegger *
+1 Michael Dürig *
Thanks for voting!
I'll push the release out,
alex
Hi
With my Sling hat on: Toby's variant 2 (JCR Client, e.g. Sling
AuthenticationHandler, should do the work) sounds wrong to me. Because for
Sling, this is just an opaque user name and there is no reason, why the generic
JCR client should interpret it in any way - after all the JCR client
Hi,
On Tue, Apr 8, 2014 at 11:09 AM, Felix Meschberger fmesc...@adobe.com wrote:
If the domain in the user name should be handled with significance, this
should
be done by the LoginModule assuming significance.
+1, I would expect such details to remain hidden within the
authentication
Hi,
As part of OAK-1702 I have added a benchmark to compare the
performance of Full text query search with JR2
Based on approach taken (which might be wrong) I get following numbers
Apache Jackrabbit Oak 0.21.0-SNAPSHOT
# FullTextSearchTest C min 10% 50% 90%
max
On Tue, Apr 8, 2014 at 8:09 AM, Felix Meschberger fmesc...@adobe.com wrote:
Hi
With my Sling hat on: Toby's variant 2 (JCR Client, e.g. Sling
AuthenticationHandler, should do the work) sounds wrong to me. Because for
Sling, this is just an opaque user name and there is no reason, why the
Hi,
in the MongoDocumentStore, it depends on what method is used whether
conditional checks in the UpdateOp happen or not.
I believe I have copied these checks correctly in RDBDocumentStore, but
still wonder why this is needed?
If a call doesn't need conditional checks, why is it made with
I can't comment to the exact meaning of the warning, but I can say the impact
of reading from multiple threads with one session is a significant concern in
itself given the current implementation of Oak. Under high throughput
conditions the lock contention quickly becomes a significant
