Re: [Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 932 - Still Failing
I filed https://issues.apache.org/jira/browse/INFRA-12056 for this. Michael On 3.6.16 9:56 , Michael Dürig wrote: Many builds started to fail with this recently: Unpacking https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.2.1/apache-maven-3.2.1-bin.zip to /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/maven-3.2.1 on jenkins-test-ebd [unittesting] $ /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/maven-3.2.1/bin/mvn -Dnsfixtures=SEGMENT_MK -Dlabel=Ubuntu -Djdk=latest1.7 -Dprofile=unittesting clean verify -Punittesting -Dsurefire.skip.ut=true -Prdb-derby -DREMOVEMErdb.jdbc-url=jdbc:derby:oaktest\;create=true [ERROR] Error executing Maven. [ERROR] 1 problem was encountered while building the effective settings [FATAL] Non-parseable settings /home/jenkins/.m2/settings.xml: unexpected character in markup % (position: START_TAG seen ...\n <%... @14:18) @ /home/jenkins/.m2/settings.xml, line 14, column 18 Is this something we can fix on our end or do we need to go through infra here? Michael On 3.6.16 6:16 , Apache Jenkins Server wrote: The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #932) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/932/ to view the results. Changes: [alexparvulescu] OAK-4423 Possible overflow in checkpoint creation [alexparvulescu] OAK-4423 Possible overflow in checkpoint creation - fix for oak-segment [mduerig] OAK-4291: FileStore.flush prone to races leading to corruption Make [mduerig] OAK-4138: Decouple revision cleanup from the flush thread FIXME tag [mreutegg] OAK-4361: Reduce performance impact of observation ACFilter Test results: 1 tests failed. FAILED: org.apache.jackrabbit.oak.segment.CompactionAndCleanupIT.checkpointDeduplicationTest Error Message: expected:<[d01586b5-0753-4bfb-a691-213050c43fd3]:261932> but was:<[12295199-c7e5-4dcf-a5ec-e4419d8310eb]:261932> Stack Trace: org.junit.ComparisonFailure: expected:<[d01586b5-0753-4bfb-a691-213050c43fd3]:261932> but was:<[12295199-c7e5-4dcf-a5ec-e4419d8310eb]:261932> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.apache.jackrabbit.oak.segment.CompactionAndCleanupIT.checkpointDeduplicationTest(CompactionAndCleanupIT.java:686) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) 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:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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)
Re: [VOTE] Release Apache Jackrabbit Oak 1.5.3
+1 2016-06-06 17:04 GMT+02:00 Davide Giannella : > A candidate for the Jackrabbit Oak 1.5.3 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.5.3/ > > The release candidate is a zip archive of the sources in: > > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.5.3/ > > The SHA1 checksum of the archive is > 366809a6ea4237a13579032b89c83837603b44ae. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh oak 1.5.3 > 366809a6ea4237a13579032b89c83837603b44ae > > Please vote on releasing this package as Apache Jackrabbit Oak 1.5.3. > 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 1.5.3 > [ ] -1 Do not release this package because... > > Davide >
Re: Usecases around Binary handling in Oak
Hi, > I still don't believe that Oak is the right place to implement these >solutions. What would be the right place then? The Oak user can store the path of the file as a string, but he would lose some features (garbage collection for example). >Every use case you outlined requires Oak to expose the location of the >binary objects in the underlying storage. I don't think every one. I think only UC1 and UC8 need it, read-only. If not already on the file system, we could copy the file to the file system (for example to the temp directory). UC2: already supported using references UC3: could be implemented with "fast random access reads" and changes in Tika. UC4: could we add a method "writeTo(WritableByteChannel target)"? UC5: The SHA-1 hash could be exposed if available, I don't see why not. Plus maybe UC1 or UC4. UC6: sounds like UC5 UC7: we would need details (how many writes, do we need a new identifier for each write operation,...). Can be implemented quite efficiently for the BlobStore implementations (MongoBlobStore / RDBBlobStore / FileBlobStore). >As soon as a file path, a file >descriptor or an S3 object ID traverses the boundary between Oak and its >clients, all bets are off. Well, we would need to define the exact contract, and maybe access rights. > is the correctness of Oak depending on the behaviour of the user? To some extend, this is already the case. Regards, Thomas
[Oak origin/1.4] Apache Jackrabbit Oak matrix - Build # 939 - Still Failing
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #939) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/939/ to view the results. Changes: [thomasm] OAK-4437 Backport OAK-4387 (XPath: querying for nodes named "text"...) Test results: 1 tests failed. FAILED: org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete[MyFixture: RDB-Derby(embedded)] Error Message: null Stack Trace: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.junit.Assert.assertFalse(Assert.java:74) at org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest.testUpdateAndDelete(RDBBlobStoreTest.java:187) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) 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:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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)
Re: svn commit: r1747246 [1/2] - in /jackrabbit/oak/trunk: oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/ oak-auth-external/src/main/java/org/apa
On 2016-06-07 16:45, f...@apache.org wrote:
Modified:
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java
URL:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java?rev=1747246&r1=1747245&r2=1747246&view=diff
==
---
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java
(original)
+++
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java
Tue Jun 7 14:45:31 2016
@@ -119,7 +119,7 @@ import com.google.common.collect.Sets;
* derived from an Oak path, and the value is a serialization of a
* {@link Document} (or a part of one). Additional fields are used for queries,
* debugging, and concurrency control:
- *
+ *
*
*
* Column
...
And this is better exactly how?
Best regards, Julian
[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 941 - Failure
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#941)
Status: Failure
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/941/ to view
the results.
Changes:
[mduerig] OAK-4373: Refactor SegmentTracker Change SegmentWriters into
[mduerig] OAK-4283: Align GCMonitor API with implementation Refactor delegating
[mduerig] OAK-4277: Finalise de-duplication caches Refactor WriteCacheManager
and
[mduerig] OAK-4277: Finalise de-duplication caches Promote FileStoreBuilder to
top
[mduerig] OAK-4277: Finalise de-duplication caches - Invalidate caches through
an
[mduerig] OAK-4277: Finalise de-duplication caches Javadoc
[mduerig] OAK-4277: Finalise de-duplication caches Javadoc
[mduerig] OAK-4434: Remove segment version argument from segment writer and and
[mduerig] OAK-4277: Finalise de-duplication caches Session refresh on gc test
for
[mduerig] OAK-4277: Finalise de-duplication caches Fix session refresh on gc
test
[frm] OAK-4102 - Break cyclic dependency of FileStore and SegmentTracker
[chetanm] OAK-4428 - Optimize RevisionVector methods
[chetanm] OAK-4431 - Index path property should be considered optional for copy
on
[chetanm] OAK-4427 - NodeDocument.fromString should also seal the returned
[chetanm] OAK-4431 - Index path property should be considered optional for copy
on
[alexparvulescu] OAK-4279 Rework offline compaction - forgot a system out call
[mduerig] OAK-4438: Segments created by an unsuccessful compaction run should
get
[thomasm] OAK-4170 QueryEngine adding invalid property restriction for fulltext
[frm] OAK-4439 - Fix the errors reported by the Javadoc tool in JDK8
[tomekr] OAK-4420: segment to segment-tar should migrate checkpoint info
[mduerig] OAK-2405: Monitoring to track old NodeStates Annotate the ids of gc'ed
[mduerig] OAK-4436: HeavyWriteIT sporadically fails Replace constant with
default
[mduerig] OAK-4436: HeavyWriteIT sporadically fails More precise excpetion
message
[mduerig] OAK-4436: HeavyWriteIT sporadically fails Comment
[amitj] OAK-4429: [oak-blob-cloud] S3Backend#getAllIdentifiers should not store
[amitj] OAK-4330: DataStoreBlobStore#getAllChunkIds fetches DataRecord when not
Test results:
9 tests failed.
FAILED:
org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT.testProxyFlippedStartByte
Error Message:
expected:<{ root = { ... } }> but was:<{ root : { } }>
Stack Trace:
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:193)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxyFlippedStartByte(DataStoreTestBase.java:137)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
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.
Re: svn commit: r1747246 [1/2] - in /jackrabbit/oak/trunk: oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/ oak-auth-external/src/main/java/org/apa
On 2016-06-08 07:14, Julian Reschke wrote:
On 2016-06-07 16:45, f...@apache.org wrote:
Modified:
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java
URL:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java?rev=1747246&r1=1747245&r2=1747246&view=diff
==
---
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java
(original)
+++
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java
Tue Jun 7 14:45:31 2016
@@ -119,7 +119,7 @@ import com.google.common.collect.Sets;
* derived from an Oak path, and the value is a serialization of a
* {@link Document} (or a part of one). Additional fields are used
for queries,
* debugging, and concurrency control:
- *
+ *
*
*
* Column
...
And this is better exactly how?
Best regards, Julian
OK, I get it: it's better in that JDK8's docLint is happy, despite there
being no actual improvement. (Note that the summary attribute is marked
"obsolete" in HTML5).
My bigger concern is that we don't enforce docLine compliance, so
Javadoc problems will creep back in, until somebody fixes all of them
and does a large commit. However, fixing things this way is bad for
change tracking and back ports.
Best regards, Julian
