buildbot exception in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a new failure on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4768 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574751 Blamelist: tripod BUILD FAILED: exception compile sincerely, -The Buildbot
buildbot success in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a restored build on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4767 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574750 Blamelist: tripod Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a new failure on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4766 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574731 Blamelist: tripod BUILD FAILED: failed compile sincerely, -The Buildbot
Index definition with unregistered namespace
Hi,
I recently encountered a bug where someone created an index definition
in the initial content, that contains a property name with a namespace
that was never registered. something like:
IndexUtils.createIndexDefinition(builder, "test", true, false,
singleton("foo:testproperty"), null);
the index was created, but then later, accessing the index node
through JCR failed.
I wanted to create a test and an issue, but have difficulties to find
an existing test to copy from :-)
any hints?
thanks.
regards, toby
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4582 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574678 Blamelist: jukka Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4581 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574668 Blamelist: mduerig BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4580 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574648 Blamelist: mreutegg Build succeeded! sincerely, -The Buildbot
buildbot success in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a restored build on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4760 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574626 Blamelist: jukka Build succeeded! sincerely, -The Buildbot
Re: permission store & rep:modCount
Hi, I created a test that created a node structure with 10k node, each having 1 ACL and 1 ACE for the everyone principle. then, with concurrent reader sessions, I read the nodes randomly. Benchmarks: ConcurrentEveryoneACLTest (oak 0.19-SNAPSHOT with everyone cache) Fixtures: Oak-Tar Runtime: 5 Num Items: 1000 Concurrency: 1,2,4,8,10,15,20,50 -- Executing benchmarks as admin: false on Oak-Tar --- # ConcurrentEveryoneACLTest , C,min,10%,50%,90%, max, N Oak-Tar , 1, 11, 12, 13, 14, 19,391 Oak-Tar , 2, 12, 13, 14, 17, 27,675 Oak-Tar , 4, 15, 16, 19, 23, 55, 1020 Oak-Tar , 8, 31, 50, 53, 56, 114,743 Oak-Tar , 10, 56, 66, 70, 76, 142,708 Oak-Tar , 15, 74,104,110,117, 132,687 Oak-Tar , 20, 92,136,145,154, 169,698 Oak-Tar , 50,156,353,384,411, 476,670 Executing benchmarks as admin: true on Oak-Tar --- # ConcurrentEveryoneACLTest , C,min,10%,50%,90%, max, N Oak-Tar , 1, 4, 5, 5, 6, 17,900 Oak-Tar , 2, 5, 5, 6, 8, 21, 1526 Oak-Tar , 4, 6, 7, 8, 11, 26, 2318 Oak-Tar , 8, 13, 24, 26, 33, 68, 1420 Oak-Tar , 10, 19, 30, 33, 46, 79, 1395 Oak-Tar , 15, 40, 47, 52, 76, 120, 1345 Oak-Tar , 20, 36, 61, 67, 94, 145, 1395 Oak-Tar , 50,115,158,179,255, 310, 1325 then I simply disabled the gloabal everyone cache the result is really bad (the 50 cocurrent actually never completed after 2 minutes?): # ConcurrentEveryoneACLTest , C,min,10%,50%,90%, max, N Oak-Tar , 1, 41, 42, 43, 49, 54,112 Oak-Tar , 2, 56, 57, 62, 74, 125,158 Oak-Tar , 4, 75, 96,117,132, 211,171 Oak-Tar , 8,261,321,346,419, 471,117 Oak-Tar , 10,475,495,519, 6532, 6549, 70 Oak-Tar , 15, 7646, 7647, 7655, 7660, 7661, 15 Oak-Tar , 20, 26988, 26995, 27010, 27015, 27016, 20 On the bright side, the creation of the ACLs is better for higher concurrency without the modcount: with mod-count: # ConcurrentWriteACLTest, C,min,10%,50%,90%, max, N Oak-Mongo , 1,197,211,227,276, 330, 21 Oak-Mongo , 2,210,212,231, 1366, 4688, 22 Oak-Mongo , 4,200,208,232, 3864, 4990, 24 Oak-Mongo , 8,201,238, 1520, 4480, 4554, 27 Oak-Mongo , 10,202,216, 1584, 5286, 6671, 28 Oak-Mongo , 15,225,740, 3005, 7695, 8254, 28 Oak-Mongo , 20,219,238, 3684, 8701, 10770, 34 Oak-Mongo , 50, 3951, 7631, 12557, 16893, 17828, 52 without mod-count: # ConcurrentWriteACLTest, C,min,10%,50%,90%, max, N Oak-Mongo , 1,201,206,219,259, 268, 23 Oak-Mongo , 2,185,194,216,616, 4561, 24 Oak-Mongo , 4,191,194,375, 2434, 3091, 20 Oak-Mongo , 8,207,469,603, 2865, 3962, 38 Oak-Mongo , 10,510,676,782, 1053, 1417, 65 Oak-Mongo , 15,965, 1223, 1344, 1673, 2137, 56 Oak-Mongo , 20,994, 1211, 1607, 2033, 2661, 66 Oak-Mongo , 50, 3359, 3496, 3947, 4655, 5559, 96 and a quick test with storing the permissions directly in the content: # ConcurrentWriteACLTest, C,min,10%,50%,90%, max, N Oak-Tar , 1, 30, 32, 35, 39, 48,143 Oak-Tar , 2, 71, 77, 79, 84, 106,126 Oak-Tar , 4, 48,159,161,164, 168,125 Oak-Tar
Re: buildbot failure in ASF Buildbot on oak-trunk
Hi, On Wed, Mar 5, 2014 at 2:33 PM, wrote: > http://ci.apache.org/builders/oak-trunk/builds/4579 Running org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest Tests run: 2, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 0.415 sec <<< FAILURE! concurrentUpdates(org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest) Time elapsed: 0.413 sec <<< FAILURE! java.lang.AssertionError: expected:<1000> but was:<1020> 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.junit.Assert.assertEquals(Assert.java:456) at org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest.concurrentUpdates(ConcurrentConflictTest.java:189) at org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest.concurrentUpdates(ConcurrentConflictTest.java:83) BR, Jukka Zitting
jackrabbit-oak build #3585: Errored
Build Update for apache/jackrabbit-oak - Build: #3585 Status: Errored Duration: 3002 seconds Commit: 7f4e3f8400f0bc51aa83c0edc4ad0135856863fe (trunk) Author: Tobias Bocanegra Message: @trivial adding another test git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1574614 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/3a406e642ed3...7f4e3f8400f0 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/20155028 -- sent by Jukka's Travis notification gateway
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4579 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574627 Blamelist: jukka BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot failure in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a new failure on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4759 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574614 Blamelist: tripod BUILD FAILED: failed compile sincerely, -The Buildbot
Re: [VOTE] Release Apache Jackrabbit Oak 0.18
On 2014-03-05 11:34, Alex Parvulescu wrote: ... [ ] +1 Release this package as Apache Jackrabbit Oak 0.18 [ ] -1 Do not release this package because... My vote is +1 best, alex [X] +1 Release this package as Apache Jackrabbit Oak 0.18
Re: permission store & rep:modCount
hi >I looked at the problem again. Removing the mod-count improves >concurrency when writing ACLs a lot (about 2 times faster with mongo >and 20 threads). the read-performance does not suffer much with the >current tests - but then the tests might not be accurate. the >permission cache is only used to the everyone permissions, so it will >show on systems with many of those. i created https://issues.apache.org/jira/browse/OAK-1504 such that can cover any kind of performance drop with benchmark test. let's have some accurate test-setup that allows us to get reliable figures if with and without that everyone cache and the concurrency issues associated with the mod-count. >bottom line: for now, I'll remove the everyone cache and the mod-count >again. after the 1.0 release, we should review the permission store >and handling. i would appreciate if you could write the benchmark tests upfront such that we can actually make any kind of statement wrt effect and potentially decide on how to deal with it. thanks a lot angela
buildbot success in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a restored build on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4758 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574575 Blamelist: jukka Build succeeded! sincerely, -The Buildbot
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4574 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574520 Blamelist: jukka Build succeeded! sincerely, -The Buildbot
Re: permission store & rep:modCount
Hi, I looked at the problem again. Removing the mod-count improves concurrency when writing ACLs a lot (about 2 times faster with mongo and 20 threads). the read-performance does not suffer much with the current tests - but then the tests might not be accurate. the permission cache is only used to the everyone permissions, so it will show on systems with many of those. I also looked at jukkas approach of storing the ACLs in content/:permissions, and it improves concurrency even more (about 3 faster times), but the read performance dropped by 50%. but this was with a stupid algorithm. I think that we can improve the :permissions approach, but also would need to change the way the permissions are exposed in the API/SPI. currently they are orthogonally provided by the PermissionProvider in so called TreePermissions. I think it could simplify a lot, if they would be part of the Tree API with something like Tree.getPermissions(). but this requires more refactoring. bottom line: for now, I'll remove the everyone cache and the mod-count again. after the 1.0 release, we should review the permission store and handling. regards, toby
Re: buildbot failure in ASF Buildbot on oak-trunk-win7
Hi, On Wed, Mar 5, 2014 at 10:07 AM, wrote: > Full details are available at: > http://ci.apache.org/builders/oak-trunk-win7/builds/4756 The problem was: Running org.apache.jackrabbit.oak.spi.commit.BackgroundObserverTest Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.031 sec <<< FAILURE! concurrentObservers(org.apache.jackrabbit.oak.spi.commit.BackgroundObserverTest) Time elapsed: 5.031 sec <<< FAILURE! java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.jackrabbit.oak.spi.commit.BackgroundObserverTest.concurrentObservers(BackgroundObserverTest.java:60) BR, Jukka Zitting
buildbot failure in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a new failure on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4756 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574520 Blamelist: jukka BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot exception in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a new failure on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4755 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574491 Blamelist: thomasm BUILD FAILED: exception compile sincerely, -The Buildbot
Re: buildbot failure in ASF Buildbot on oak-trunk
This looks similar than what we have been seeing earlier today: concurrent[2](org.apache.jackrabbit.oak.jcr.ConcurrentFileOperationsTest) Time elapsed: 0.181 sec <<< ERROR! java.lang.Exception: session-0 jcr:primaryType: nt:unstructured file-0.bin jcr:created: 2014-03-05T14:06:09.722Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:09.681Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: 21faf7f4-bf73-4c6b-bf3b-0f9855c40f08 file-1.bin jcr:created: 2014-03-05T14:06:09.750Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:09.746Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: 9809ff1c-e0a8-42e6-925b-53a88c8db7df file-2.bin jcr:created: 2014-03-05T14:06:09.807Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:09.807Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: daf63ddb-f4d3-4eb8-89cd-afae23ba30ca file-3.bin jcr:created: 2014-03-05T14:06:09.858Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:09.858Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: 91fd2ee6-6cd2-4e99-9f99-99e163077271 file-4.bin jcr:created: 2014-03-05T14:06:09.923Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:09.922Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: 8a1f1f43-445e-4eb6-82ed-1a1fa1232859 file-5.bin jcr:created: 2014-03-05T14:06:09.993Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:09.993Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: 7bf9168b-8d2a-4655-917f-53012306aa54 file-6.bin jcr:created: 2014-03-05T14:06:10.058Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:10.058Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: 286200da-0fd2-410c-ae46-9da9eef77400 file-7.bin jcr:created: 2014-03-05T14:06:10.102Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:10.101Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:primaryType: nt:resource jcr:lastModifiedBy: admin jcr:uuid: b9873f78-ca49-421e-8378-8801f8dfda39 file-8.tmp jcr:created: 2014-03-05T14:06:10.220Z jcr:createdBy: admin jcr:primaryType: nt:file jcr:content jcr:lastModified: 2014-03-05T14:06:10.220Z jcr:mimeType: application/octet-stream jcr:data: `? ?8Q?? jcr:uuid: 196aef49-249b-472b-b093-aa4457e9a2be jcr:lastModifiedBy: admin jcr:primaryType: nt:resource at org.apache.jackrabbit.oak.jcr.ConcurrentFileOperationsTest$1.run(ConcurrentFileOperationsTest.java:110) at java.lang.Thread.run(Thread.java:701) Caused by: javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /test-node/session-0 at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:237) at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:502) at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:389) at org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.perform(SessionImpl.java:414) at org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.perform(SessionImpl.java:411) at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:157) at org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:124) at org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:411) at org.apache.jackrabbit.oak.jcr.ConcurrentFileOperationsTest$1.run(ConcurrentFileOperationsTest.java:101) ... 1 more Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved conflicts in /test-node/session-0 at org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidato
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4573 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574491 Blamelist: thomasm BUILD FAILED: failed compile sincerely, -The Buildbot
RE: [VOTE] Release Apache Jackrabbit Oak 0.18
> Please vote on releasing this package as Apache Jackrabbit Oak 0.18. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. +1 Release this package as Apache Jackrabbit Oak 0.18 All checks OK. Regards Marcel
jackrabbit-oak build #3579: Passed
Build Update for apache/jackrabbit-oak - Build: #3579 Status: Passed Duration: 2298 seconds Commit: 69db4072c31277c37ea7d3f73ef323c26b0da713 (trunk) Author: Davide Giannella Message: OAK-1263 another round of formatting View the changeset: https://github.com/apache/jackrabbit-oak/pull/9 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/20126131 -- sent by Jukka's Travis notification gateway
Re: [VOTE] Release Apache Jackrabbit Oak 0.18
On 05/03/2014 10:34, Alex Parvulescu wrote: > [ ] +1 Release this package as Apache Jackrabbit Oak 0.18 > [ ] -1 Do not release this package because... +1
jackrabbit-oak build #3577: Errored
Build Update for apache/jackrabbit-oak - Build: #3577 Status: Errored Duration: 3002 seconds Commit: 64d93bd2dc1def2ab1c38716437306d59aa81ad7 (trunk) Author: Michael Duerig Message: OAK-1491: ObservationTest failure on Windows Add some instrumentation to test case to detect spurious wake-up on futures git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1574414 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/033b478fd71e...64d93bd2dc1d View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/20122887 -- sent by Jukka's Travis notification gateway
Re: [VOTE] Release Apache Jackrabbit Oak 0.18
On 5.3.14 11:34 , Alex Parvulescu wrote: [X] +1 Release this package as Apache Jackrabbit Oak 0.18 Michael
jackrabbit-oak build #3576: Passed
Build Update for apache/jackrabbit-oak - Build: #3576 Status: Passed Duration: 2315 seconds Commit: 8de6dc6ab49eaa430492d6f1500ddafe0f716d90 (jackrabbit-oak-0.18) Author: Alexandru Parvulescu Message: [maven-release-plugin] copy for tag jackrabbit-oak-0.18 git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.18@1574408 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/commit/8de6dc6ab49e View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/20120913 -- sent by Jukka's Travis notification gateway
[VOTE] Release Apache Jackrabbit Oak 0.18
A candidate for the Jackrabbit Oak 0.18 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/oak/0.18/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.18/ The SHA1 checksum of the archive is ce4caf641f222f8092cae1e58a46c272c55b6cf0. A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-1005/ The command for running automated checks against this release candidate is: $ sh check-release.sh oak 0.18 ce4caf641f222f8092cae1e58a46c272c55b6cf0 Please vote on releasing this package as Apache Jackrabbit Oak 0.18. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 0.18 [ ] -1 Do not release this package because... My vote is +1 best, alex
buildbot success in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a restored build on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4750 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574402 Blamelist: alexparvulescu Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on oak-trunk-win7
The Buildbot has detected a new failure on builder oak-trunk-win7 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk-win7/builds/4749 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-win7 Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1574397 Blamelist: tommaso BUILD FAILED: failed compile sincerely, -The Buildbot
RE: jackrabbit-oak build #3572: Broken
hmm, looks like the test tries to bootstrap the repository even though it
already happened in the @Before method...
Regards
Marcel
> Haven't seen this before:
>
> rebaseVisibility(org.apache.jackrabbit.oak.jcr.ConcurrentAddNodesClusterIT
> )
> Time elapsed: 11.26 sec <<< ERROR!
> java.lang.RuntimeException:
> org.apache.jackrabbit.oak.api.CommitFailedException: OakMerge0001:
> OakMerge0001: Failed to merge changes to the underlying store (retries
> 4, 5443 ms)
> at
> org.apache.jackrabbit.oak.spi.lifecycle.OakInitializer.initialize(OakInitializer.ja
> va:67)
> at
> org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:498)
> at org.apache.jackrabbit.oak.jcr.Jcr.createRepository(Jcr.java:159)
> at
> org.apache.jackrabbit.oak.jcr.ConcurrentAddNodesClusterIT.rebaseVisibility(
> ConcurrentAddNodesClusterIT.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
> Method.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.jav
> a:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(Framework
> Method.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMeth
> od.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.j
> ava:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.j
> ava: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.internal.runners.statements.RunBefores.evaluate(RunBefores.java
> :28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.jav
> a:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Prov
> ider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java
> :112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(Refl
> ectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(Pr
> oviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(Provider
> Factory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Forked
> Booter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:7
> 5)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakMerge0001: OakMerge0001: Failed to merge changes to the underlying
> store (retries 4, 5443 ms)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch.merge(Abstra
> ctNodeStoreBranch.java:304)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.m
> erge(DocumentNodeStoreBranch.java:143)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(D
> ocumentRootBuilder.java:147)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(D
> ocumentNodeStore.java:1187)
> at
> org.apache.jackrabbit.oak.spi.lifecycle.OakInitializer.initialize(OakInitializer.ja
> va:65)
> ... 35 more
> Caused by: org.apache.jackrabbit.mk.api.MicroKernelException: The node
> 2:/jcr:system/rep:permissionStore was already added in revision
> r144917c26ae-0-1, before
> r144917c4e6d-0-1; document:
> {_lastRev={r0-0-1=r144917c26ae-0-1},
> _id=2:/jcr:system/rep:permissionStore,
> _modified=278802048,
> _modCount=19,
> _commitRoot={r144917c26ae-0-1=0},
> _children=true,
> _deleted={r144917c26ae-0-1=false},
> jcr:primaryType={r144917c26ae-0-1="nam:rep:PermissionStore"}},
> revision order:
> 1:
> r144917c
RE: permission store & rep:modCount
Hi, > FWIW DocumentNodeStore maintains a property '_modCount' on a per node > basis and it can possibly be exposed as part of NodeStore as a hidden > property. the _modCount is not sufficiently accurate. it does not take pending updates of the _lastRev into account. we'd have to use DocumentNodeState#lastRevision. this reflects the last modification on that node or some descendant node. Regards Marcel
Re: jackrabbit-oak build #3572: Broken
Haven't seen this before:
rebaseVisibility(org.apache.jackrabbit.oak.jcr.ConcurrentAddNodesClusterIT)
Time elapsed: 11.26 sec <<< ERROR!
java.lang.RuntimeException:
org.apache.jackrabbit.oak.api.CommitFailedException: OakMerge0001:
OakMerge0001: Failed to merge changes to the underlying store (retries
4, 5443 ms)
at
org.apache.jackrabbit.oak.spi.lifecycle.OakInitializer.initialize(OakInitializer.java:67)
at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:498)
at org.apache.jackrabbit.oak.jcr.Jcr.createRepository(Jcr.java:159)
at
org.apache.jackrabbit.oak.jcr.ConcurrentAddNodesClusterIT.rebaseVisibility(ConcurrentAddNodesClusterIT.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException:
OakMerge0001: OakMerge0001: Failed to merge changes to the underlying
store (retries 4, 5443 ms)
at
org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch.merge(AbstractNodeStoreBranch.java:304)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:143)
at
org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:147)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1187)
at
org.apache.jackrabbit.oak.spi.lifecycle.OakInitializer.initialize(OakInitializer.java:65)
... 35 more
Caused by: org.apache.jackrabbit.mk.api.MicroKernelException: The node
2:/jcr:system/rep:permissionStore was already added in revision
r144917c26ae-0-1, before
r144917c4e6d-0-1; document:
{_lastRev={r0-0-1=r144917c26ae-0-1},
_id=2:/jcr:system/rep:permissionStore,
_modified=278802048,
_modCount=19,
_commitRoot={r144917c26ae-0-1=0},
_children=true,
_deleted={r144917c26ae-0-1=false},
jcr:primaryType={r144917c26ae-0-1="nam:rep:PermissionStore"}},
revision order:
1:
r144917c28dc-2-1:r144917c28dc-3-0
at
org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:500)
at
org.apache.jackrabbit.oak.plugins.document.Commit.createOrUpdateNode(Commit.java:418)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:303)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:203)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:188)
jackrabbit-oak build #3572: Broken
Build Update for apache/jackrabbit-oak - Build: #3572 Status: Broken Duration: 1329 seconds Commit: fde3dc1cffb120968abac8999a1a15aeb1c91b1e (trunk) Author: Michael Duerig Message: OAK-1429: Slow event listeners do not scale as expected Enable slowListener test for DocumentNS since with the latest optimisation this passes now for me git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1574394 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/c6bd81ae61c9...fde3dc1cffb1 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/20117044 -- sent by Jukka's Travis notification gateway
Re: permission store & rep:modCount
Hi, My suggestion would be to (additionally or only) expose the current cluster node id in some way. That way, oak-core (mainly hooks I guess; for example index implementations) can create properties and nodes that are known to not conflict with changes of other cluster nodes. Regards, Thomas On 04/03/14 15:37, "Chetan Mehrotra" wrote: >FWIW DocumentNodeStore maintains a property '_modCount' on a per node >basis and it can possibly be exposed as part of NodeStore as a hidden >property. > >And that can be used to maintain the cache. DocumentNodeStore itself >internally relies on this to keep its caches in consistent state >Chetan Mehrotra > > >On Fri, Feb 28, 2014 at 7:52 AM, Jukka Zitting >wrote: >> Hi, >> >> On Thu, Feb 27, 2014 at 4:46 PM, Tobias Bocanegra >>wrote: >>> the current implementation allows to read all ACLs for a given >>> principal very efficiently at once with no false hasNode() accesses. >> >> Good point. >> >> To avoid has/getNode() misses (that can be expensive with MongoMK) in >> the proposed alternative, it would probably be a good idea to store a >> :hasPermissions flag property (or something similar) in each node with >> an ACL attached to it. Such a property could even be something like >> :permissionModCount in case in-memory caching (and cache invalidation) >> is still needed. >> >> BR, >> >> Jukka Zitting
Re: why do we index 'rep%3AGrantACE' ?
On 05/03/2014 00:58, Jukka Zitting wrote: > I remember myself searching at least for rep:AccessControllable on > various occasions. It's a quick and easy way to locate ACLs within a > repository. I searched many times in CQ for the rep:ACL for packaging ACLs and moving them from one environment to the other. http://goo.gl/wZdWeL Cheers D.
