[jira] [Updated] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimulatenousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4078:

Description: 


{noformat}
Error Message

only one gc should throw exception  expected:<1> but was:<0>

Stacktrace

junit.framework.AssertionFailedError: only one gc should throw exception  
expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:199)
at 
org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
{noformat}


Minimally, the diagnostics are misleading. Maybe the first garbage collector 
completes too soon?

  was:


{noformat}
Error Message

only one gc should throw exception  expected:<1> but was:<0>

Stacktrace

junit.framework.AssertionFailedError: only one gc should throw exception  
expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:199)
at 
org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
{noformat}


Minimally, the diagnostics are misleading.


> occasional test failure in GarbageCollectorTest.testSimulatenousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading. Maybe the first garbage collector 
> completes too soon?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimulatenousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4078:

Description: 


{noformat}
Error Message

only one gc should throw exception  expected:<1> but was:<0>

Stacktrace

junit.framework.AssertionFailedError: only one gc should throw exception  
expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:199)
at 
org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
{noformat}


Minimally, the diagnostics are misleading.

  was:


Error Message

only one gc should throw exception  expected:<1> but was:<0>

Stacktrace

junit.framework.AssertionFailedError: only one gc should throw exception  
expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:199)
at 
org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)



> occasional test failure in GarbageCollectorTest.testSimulatenousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimulatenousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4078:

Component/s: (was: jackrabbit-data)

> occasional test failure in GarbageCollectorTest.testSimulatenousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimulatenousRunGC

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4078:
---

 Summary: occasional test failure in 
GarbageCollectorTest.testSimulatenousRunGC
 Key: JCR-4078
 URL: https://issues.apache.org/jira/browse/JCR-4078
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-data
Reporter: Julian Reschke




Error Message

only one gc should throw exception  expected:<1> but was:<0>

Stacktrace

junit.framework.AssertionFailedError: only one gc should throw exception  
expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:199)
at 
org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT][VOTE] Release Apache Jackrabbit 2.12.6

[Amit Jain]

Hi,

The vote passes as follows:

+1 Julian Reschke
+1 Koll Claus
+1 Amit Jain

Thanks for voting. I'll push the release out.

Regards
Amit

[jira] [Commented] (JCR-4073) jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734473#comment-15734473
 ] 

Julian Reschke commented on JCR-4073:
-

Occurred again: 
https://builds.apache.org/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-data/2420/testReport/org.apache.jackrabbit.core.data/TestLocalCache/testAutoPurge/

> jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge
> -
>
> Key: JCR-4073
> URL: https://issues.apache.org/jira/browse/JCR-4073
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-data
>Reporter: Julian Reschke
>Assignee: Amit Jain
> Fix For: 2.14
>
>
> {noformat}
> Error Message
> a1 should be null
> Stacktrace
> junit.framework.AssertionFailedError: a1 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestLocalCache.testAutoPurge(TestLocalCache.java:197)
> {noformat}
> Maybe caused by JCR-4007?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4073) jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4073:

Fix Version/s: (was: 2.12.6)
   (was: 2.13.6)

> jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge
> -
>
> Key: JCR-4073
> URL: https://issues.apache.org/jira/browse/JCR-4073
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-data
>Reporter: Julian Reschke
>Assignee: Amit Jain
> Fix For: 2.14
>
>
> {noformat}
> Error Message
> a1 should be null
> Stacktrace
> junit.framework.AssertionFailedError: a1 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestLocalCache.testAutoPurge(TestLocalCache.java:197)
> {noformat}
> Maybe caused by JCR-4007?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (JCR-4073) jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge

[Julian Reschke (JIRA)]

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

Julian Reschke reopened JCR-4073:
-

> jackrabbit-data: occasional test failures in TestLocalCache.testAutoPurge
> -
>
> Key: JCR-4073
> URL: https://issues.apache.org/jira/browse/JCR-4073
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-data
>Reporter: Julian Reschke
>Assignee: Amit Jain
> Fix For: 2.14
>
>
> {noformat}
> Error Message
> a1 should be null
> Stacktrace
> junit.framework.AssertionFailedError: a1 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestLocalCache.testAutoPurge(TestLocalCache.java:197)
> {noformat}
> Maybe caused by JCR-4007?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Adding new cluster node when old journals were already removed by janitor thread

[Liang]

Hi, All
In page https://wiki.apache.org/jackrabbit/Clustering, there is several 
caveats if the janitor thread is enabled

The current solution has three known caveats:

If the janitor is enabled then you loose the possibility to easily add cluster 
nodes. (It is still possible but takes detailed knowledge of Jackrabbit.)
From the statement, it look we could not directly adding one new node into the 
cluster environment if some old journals has already been deleted by janitor 
thread.But based on my current understanding, during the startup,this new node 
already does following 2 things sequentially:
  Reading the whole repository, including all nodes and the version history, 
and built index for them
 Read all revisions to sync
You see, for new added node, since step#1 already reads all nodes from 
database, even some revisions are already removed, step#2 seems has no problem.
If step#2 does have problem, or there is any other potential issue. Please let 
me know or give me one example. 




Regards,
-Liang

[jira] [Commented] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()

[Alfusainey Jallow (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733624#comment-15733624
 ] 

Alfusainey Jallow commented on JCR-3995:


i tried to reproduce it at my end but did not succeed. have a look at this 
patch and test with this and see. i try to now focus the removal on only the 
affected test case. its a temporal fix -> will investigate further.

> occasional test failure in 
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
> 
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.13.0
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-3995-new.patch, JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
>   Time elapsed: 0.084 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at 
> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest.testAddingFourAccessControlEntries(AccessControlManagerImplTest.java:159)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()

[Alfusainey Jallow (JIRA)]

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

Alfusainey Jallow updated JCR-3995:
---
Attachment: JCR-3995-new.patch

> occasional test failure in 
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
> 
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.13.0
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-3995-new.patch, JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
>   Time elapsed: 0.084 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at 
> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest.testAddingFourAccessControlEntries(AccessControlManagerImplTest.java:159)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jackrabbit-trunk - Build # 2420 - Unstable

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2420)

Status: Unstable

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2420/ to 
view the results.

[jira] [Resolved] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4077.
-
Resolution: Fixed

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-4077.diff
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) Change vfs ext test cases not to depend on http client

[Woonsan Ko (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733381#comment-15733381
 ] 

Woonsan Ko commented on JCR-4077:
-

I've pushed one more commit to convert File#getPath() to unix style before 
assertion.
Thanks for the test and pointer!

Woonsan

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-4077.diff
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Restrict matrix tasks to specific nodes

[Francesco Mari]

Thanks for your help. I will monitor the build during the following
days and verify that everything is alright.

2016-12-08 20:01 GMT+01:00 Gavin McDonald :
>
>> On 8 Dec. 2016, at 9:34 pm, Francesco Mari  wrote:
>>
>> Hi,
>>
>> I recently discovered that some of the tests run by the Apache
>> Jackrabbit Oak Matrix job [1] consistently fail when matrix tasks are
>> scheduled on one of the nodes labelled "beam". I documented the
>> failures in this issue [2].
>>
>> I would like to schedule the matrix tasks to run on specific nodes or,
>> at least, not to run on the faulty ones. What is the best way to
>> achieve this?
>
> I added a ‘label’ expression to your build so that they only build on nodes 
> labelled ‘ubuntu’
>
> Let me know if that helps.
>
> (Beam and others don’t use the ‘ubuntu’ label
>
> See: https://cwiki.apache.org/confluence/display/INFRA/Jenkins+node+labels 
>  )
>
>
> Gav…
>
>>
>> Thanks,
>>
>> Francesco
>>
>> [1]: 
>> https://builds.apache.org/view/All/job/Apache%20Jackrabbit%20Oak%20matrix/
>> [2]: https://issues.apache.org/jira/browse/OAK-5017
>

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1321 - Still Failing

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-4400 - Correlate index with the index definition used to build it

[chetanm] OAK-5220 - Remove usage of NodeBuilder in IndexDefinition

[chetanm] OAK-5218 - Enable use of hybrid index before first async indexing is

[chetanm] OAK-5247 - Allow setting property node name in IndexDefinitionBuilder

[chetanm] Change the test log file name to unit-tests.log to ensure it gets

[chetanm] OAK-5248 - Use segment-tar in webapp example

[reschke] OAK-5202: update to Jackrabbit 2.13.5

[amitj] OAK-5251: Test failure:

[mduerig] OAK-4292: Document Oak segment-tar Update description of fixtures for

[frm] OAK-5252 - Disable IPv6 tests on Jenkins nodes labelled "beam"

[chetanm] OAK-5247 - Allow setting property node name in IndexDefinitionBuilder

[davide] Apache Jackrabbit Oak 1.5.15

[davide] [maven-release-plugin] prepare release jackrabbit-oak-1.5.15

[davide] [maven-release-plugin] prepare for next development iteration

 

Test results:
All tests passed

[jira] [Updated] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4077:

Attachment: JCR-4077.diff

proposed patch based on Woonsan's pull request

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-4077.diff
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Restrict matrix tasks to specific nodes

[Gavin McDonald]

> On 8 Dec. 2016, at 9:34 pm, Francesco Mari  wrote:
> 
> Hi,
> 
> I recently discovered that some of the tests run by the Apache
> Jackrabbit Oak Matrix job [1] consistently fail when matrix tasks are
> scheduled on one of the nodes labelled "beam". I documented the
> failures in this issue [2].
> 
> I would like to schedule the matrix tasks to run on specific nodes or,
> at least, not to run on the faulty ones. What is the best way to
> achieve this?

I added a ‘label’ expression to your build so that they only build on nodes 
labelled ‘ubuntu’

Let me know if that helps.

(Beam and others don’t use the ‘ubuntu’ label

See: https://cwiki.apache.org/confluence/display/INFRA/Jenkins+node+labels 
 )


Gav…

> 
> Thanks,
> 
> Francesco
> 
> [1]: 
> https://builds.apache.org/view/All/job/Apache%20Jackrabbit%20Oak%20matrix/
> [2]: https://issues.apache.org/jira/browse/OAK-5017

[jira] [Comment Edited] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732878#comment-15732878
 ] 

Julian Reschke edited comment on JCR-4077 at 12/8/16 6:36 PM:
--

Fails with:
{noformat}
Failed tests:
  
TestVFSDataStore.testSetFileSystemOptionsPropertiesInString:154->doSetFileSystemOptionsPropertiesInString:193
 expected:<[/home/tester/.ssh/]id_rsa> but was:<[\home\tester\.ssh\]id_rsa>
{noformat}

(on Windows). Would it be ok to replace backlash by slash before comparing in 
the test assertion?


was (Author: reschke):
Fails with:
{noformat}
Failed tests:
  
TestVFSDataStore.testSetFileSystemOptionsPropertiesInString:154->doSetFileSystemOptionsPropertiesInString:193
 expected:<[/home/tester/.ssh/]id_rsa> but was:<[\home\tester\.ssh\]id_rsa>
{noformat}

(on Windows). Would it be to replace backlash by slash before comparing in the 
test assertion?

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732878#comment-15732878
 ] 

Julian Reschke edited comment on JCR-4077 at 12/8/16 6:07 PM:
--

Fails with:
{noformat}
Failed tests:
  
TestVFSDataStore.testSetFileSystemOptionsPropertiesInString:154->doSetFileSystemOptionsPropertiesInString:193
 expected:<[/home/tester/.ssh/]id_rsa> but was:<[\home\tester\.ssh\]id_rsa>
{noformat}

(on Windows). Would it be to replace backlash by slash before comparing in the 
test assertion?


was (Author: reschke):
Fails with:
{noformat}
Failed tests:
  
TestVFSDataStore.testSetFileSystemOptionsPropertiesInString:154->doSetFileSystemOptionsPropertiesInString:193
 expected:<[/home/tester/.ssh/]id_rsa> but was:<[\home\tester\.ssh\]id_rsa>
{noformat}

(on Windows). Would it be OK to add a String.replace("\\", "/") to the test 
assertion?

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732878#comment-15732878
 ] 

Julian Reschke edited comment on JCR-4077 at 12/8/16 6:03 PM:
--

Fails with:
{noformat}
Failed tests:
  
TestVFSDataStore.testSetFileSystemOptionsPropertiesInString:154->doSetFileSystemOptionsPropertiesInString:193
 expected:<[/home/tester/.ssh/]id_rsa> but was:<[\home\tester\.ssh\]id_rsa>
{noformat}

(on Windows). Would it be OK to add a String.replace("\\", "/") to the test 
assertion?


was (Author: reschke):
That sounds good; will try later today!


> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4077:

Fix Version/s: 2.13.6

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.13.6, 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732878#comment-15732878
 ] 

Julian Reschke commented on JCR-4077:
-

That sounds good; will try later today!


> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4077) Change vfs ext test cases not to depend on http client

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4077:

Summary: Change vfs ext test cases not to depend on http client  (was: 
disable Jackrabbit VFS Extension (?))

> Change vfs ext test cases not to depend on http client
> --
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Woonsan Ko (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732721#comment-15732721
 ] 

Woonsan Ko commented on JCR-4077:
-

I personally don't like to keep common-http client dependency in jackrabbit. 
So, I changed the test case to use sftp fso config by default, instead of http 
fso config. That should be good enough, IMO. (In the end, I'd like to expect 
commons-vfs2 to be improved to use httpcomponents.)
People can choose either SFTP as backend or WebDAV (by adding old 
jackrabbit-webdav and commons-http client dependencies manually in their end 
projects).
Jackrabbit WebDAV and commons-httpclient do not need to be pulled in together 
with jackrabbit-vfs-ext any more.

Regards,

Woonsan

> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) disable Jackrabbit VFS Extension (?)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732707#comment-15732707
 ] 

ASF GitHub Bot commented on JCR-4077:
-

GitHub user woonsan opened a pull request:

https://github.com/apache/jackrabbit/pull/49

JCR-4077: Removing http dependency (indirect by using http-based FSO) in 
test case

I've improved the test case, TestVFSDataStore, to avoid any http related 
dependency which is made indirectly by using HttpFileSystemConfigBuilder.
The original intention was just to make sure the parameters passed to the 
FSO in the end. Not intended to test with http specifically.
Also, since Jackrabbit is removing the old commons http client dependency 
(used by the old jackrabbit-webdav), I think we'd better remove http dependency 
in test case like this fix.
Therefore, I replaced the test case to use SftpFileSystemConfigBuilder and 
sftp configuration example by default.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/woonsan/jackrabbit bugfix/JCR-4077

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jackrabbit/pull/49.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #49


commit bf241e35aa5089bc35c63f81e765b74e9707ab98
Author: Woonsan Ko 
Date:   2016-12-08T16:45:30Z

JCR-4077: Removing http dependency (indirect by using http-based FSO) in 
test case.




> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732689#comment-15732689
 ] 

Julian Reschke commented on JCR-4077:
-

What *does* seem to work is to *replace* the dependency on jackrabbit-webdav 
with one on httpclient 3.1:

{noformat}
--- jackrabbit-vfs-ext/pom.xml  (revision 1773260)
+++ jackrabbit-vfs-ext/pom.xml  (working copy)
@@ -57,16 +57,22 @@
 jackrabbit-data
 ${project.version}
 
-
 
-org.apache.jackrabbit
-jackrabbit-webdav
-${project.version}
-
-
 org.slf4j
 slf4j-api
 
+
+  commons-httpclient
+  commons-httpclient
+  3.1
+  
+
+
+  commons-logging
+  commons-logging
+
+  
+
{noformat}


> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-2406) Upgrade httpclient dependency to 4.0

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564650#comment-15564650
 ] 

Julian Reschke edited comment on JCR-2406 at 12/8/16 4:23 PM:
--

Right, we should try to avoid to make the same mistake again.

EDIT: but I don't know how to avoid it. If we provide classes that implement 
the HC4 HttpRequest interface, we'll be dependent on that.


was (Author: reschke):
Right, we should try to avoid to make the same mistake again.

> Upgrade httpclient dependency to 4.0
> 
>
> Key: JCR-2406
> URL: https://issues.apache.org/jira/browse/JCR-2406
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, jackrabbit-spi2dav
>Reporter: Sébastien Launay
>Assignee: Julian Reschke
>Priority: Blocker
> Fix For: 2.16, 2.15.0
>
>
> Httpclient is one of these libs that tends to be pulled by another third 
> party lib and often with conflicted versions (in a traditional environment 
> contrary to OSGi).
> Upgrading from 3.0 to 4.0 allows applications to use both Jackrabbit and the 
> latest release of HttpClient.
> As discussed in JCR-2389, this is a sensitive task as it can introduce 
> regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-2406) Upgrade httpclient dependency to 4.0

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732636#comment-15732636
 ] 

Julian Reschke commented on JCR-2406:
-

https://github.com/reschke/jackrabbit/tree/JCR-2406 now works with the new 
client component (early feedback appreciated).

> Upgrade httpclient dependency to 4.0
> 
>
> Key: JCR-2406
> URL: https://issues.apache.org/jira/browse/JCR-2406
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, jackrabbit-spi2dav
>Reporter: Sébastien Launay
>Assignee: Julian Reschke
>Priority: Blocker
> Fix For: 2.16, 2.15.0
>
>
> Httpclient is one of these libs that tends to be pulled by another third 
> party lib and often with conflicted versions (in a traditional environment 
> contrary to OSGi).
> Upgrading from 3.0 to 4.0 allows applications to use both Jackrabbit and the 
> latest release of HttpClient.
> As discussed in JCR-2389, this is a sensitive task as it can introduce 
> regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732606#comment-15732606
 ] 

Julian Reschke edited comment on JCR-4077 at 12/8/16 4:19 PM:
--

No, it doesn't help:
{noformat}
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.617 sec <<< 
FAILURE! - in org.apache.jackrabbit.vfs.ext.TestAll
testSetFileSystemOptionsPropertiesInString(org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore)
  Time elapsed: 0.085 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Could not create File System Options.
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore.testSetFileSystemOptionsPropertiesInString(TestVFSDataStore.java:152)

{noformat}


FWIW, you get exactly the same test failure if you remove the webdav dependency 
in trunk -- maybe it's just the test case that needs some attention?



was (Author: reschke):
No, it doesn't help:
{noformat}
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.617 sec <<< 
FAILURE! - in org.apache.jackrabbit.vfs.ext.TestAll
testSetFileSystemOptionsPropertiesInString(org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore)
  Time elapsed: 0.085 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Could not create File System Options.
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore.testSetFileSystemOptionsPropertiesInString(TestVFSDataStore.java:152)

{noformat}


FWIW, you get exactly the same test failure if you remove the webdav dependency 
in trunk.


> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732606#comment-15732606
 ] 

Julian Reschke edited comment on JCR-4077 at 12/8/16 4:15 PM:
--

No, it doesn't help:
{noformat}
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.617 sec <<< 
FAILURE! - in org.apache.jackrabbit.vfs.ext.TestAll
testSetFileSystemOptionsPropertiesInString(org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore)
  Time elapsed: 0.085 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Could not create File System Options.
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore.testSetFileSystemOptionsPropertiesInString(TestVFSDataStore.java:152)

{noformat}


FWIW, you get exactly the same test failure if you remove the webdav dependency 
in trunk.



was (Author: reschke):
No, it doesn't help:
{noformat}
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.617 sec <<< 
FAILURE! - in org.apache.jackrabbit.vfs.ext.TestAll
testSetFileSystemOptionsPropertiesInString(org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore)
  Time elapsed: 0.085 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Could not create File System Options.
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore.testSetFileSystemOptionsPropertiesInString(TestVFSDataStore.java:152)

{noformat}


> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732606#comment-15732606
 ] 

Julian Reschke commented on JCR-4077:
-

No, it doesn't help:
{noformat}
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.617 sec <<< 
FAILURE! - in org.apache.jackrabbit.vfs.ext.TestAll
testSetFileSystemOptionsPropertiesInString(org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore)
  Time elapsed: 0.085 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Could not create File System Options.
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.jackrabbit.vfs.ext.ds.TestVFSDataStore.testSetFileSystemOptionsPropertiesInString(TestVFSDataStore.java:152)

{noformat}


> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Woonsan Ko (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732448#comment-15732448
 ] 

Woonsan Ko commented on JCR-4077:
-

Hi [~julian.resc...@gmx.de],

I think the only thing related to http client (indirectly) in 
jackrabbit-vfs-ext is the following dependency:
{code}


org.apache.jackrabbit
jackrabbit-webdav
${project.version}

{code}

Actually commons-vfs2 doesn't pull in http or webdav dependencies automatically 
either (by using optional).
The reason why jackrabbit-webdav was put there initially was simply because it 
was regarded easier to use webdav backend because commons-vfs2 webdav url uses 
jackrabbit-webdav library. However, that was unnecessary. When people want to 
use webdav backend with vfs2, they can add all the optional libraries as well. 
That's the intention of optional dependencies in commons-vfs2.

Anyway, I think if we simply remove the jackrabbit-webdav dependency, then it 
will work fine. (At least for both local FS and SFTP backend.)

Could you please remove the jackrabbit-webdav dependency locally and see if it 
helps?

Thanks in advance,

Woonsan

> disable Jackrabbit VFS Extension (?)
> 
>
> Key: JCR-4077
> URL: https://issues.apache.org/jira/browse/JCR-4077
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-vfs-ext
>Affects Versions: 2.13.6
>Reporter: Julian Reschke
> Fix For: 2.14
>
>
> Switching to the new httpclient code will break jackrabbit-vfs-ext, which has 
> a dependency on the older version.
> (Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Oak 1.4.11 release plan

[Davide Giannella]

Hello team,

I'm planning to cut Oak on Monday 12th Dec.

If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.

Thanks
Davide

[jira] [Commented] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732285#comment-15732285
 ] 

Julian Reschke commented on JCR-3995:
-

Running the integration tests multiple times, I now sometimes get:
{noformat}
Running org.apache.jackrabbit.jcr2dav.ConformanceTest
Tests run: 2344, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 184.797 sec 
<<< FAILURE! - in org.apache.jackrabbit.jcr2dav.ConformanceTest
testElementTest(org.apache.jackrabbit.test.api.query.ElementTest)  Time 
elapsed: 0.074 sec  <<< FAILURE!
junit.framework.AssertionFailedError: /testroot/rep:policy is not expected to 
be part of the result set
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at 
org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:384)
at 
org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeXPathQuery(AbstractQueryTest.java:315)
at 
org.apache.jackrabbit.test.api.query.ElementTest.testElementTest(ElementTest.java:63)

testElementTestAnyNode(org.apache.jackrabbit.test.api.query.ElementTest)  Time 
elapsed: 0.07 sec  <<< FAILURE!
junit.framework.AssertionFailedError: /testroot/rep:policy is not expected to 
be part of the result set
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at 
org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:384)
at 
org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeXPathQuery(AbstractQueryTest.java:315)
at 
org.apache.jackrabbit.test.api.query.ElementTest.testElementTestAnyNode(ElementTest.java:77)

testElementTestAnyNodeNtBase(org.apache.jackrabbit.test.api.query.ElementTest)  
Time elapsed: 0.072 sec  <<< FAILURE!
junit.framework.AssertionFailedError: /testroot/rep:policy is not expected to 
be part of the result set
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at 
org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:384)
at 
org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeXPathQuery(AbstractQueryTest.java:315)
at 
org.apache.jackrabbit.test.api.query.ElementTest.testElementTestAnyNodeNtBase(ElementTest.java:92)

testGetSize(org.apache.jackrabbit.test.api.query.QueryResultNodeIteratorTest)  
Time elapsed: 0.071 sec  <<< FAILURE!
junit.framework.AssertionFailedError: NodeIterator.getSize does not return 
correct number. expected:<4> but was:<5>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:134)
at 
org.apache.jackrabbit.test.api.query.QueryResultNodeIteratorTest.testGetSize(QueryResultNodeIteratorTest.java:64)

testOrder(org.apache.jackrabbit.jcr2spi.NodeOrderTest)  Time elapsed: 0.047 sec 
 <<< FAILURE!
junit.framework.AssertionFailedError: Wrong order of child nodes returned by 
Node.getNodes().
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at 
org.apache.jackrabbit.jcr2spi.NodeOrderTest.checkOrder(NodeOrderTest.java:65)
at 
org.apache.jackrabbit.jcr2spi.NodeOrderTest.testOrder(NodeOrderTest.java:80)

{noformat}


> occasional test failure in 
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
> 
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.13.0
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
>   Time elapsed: 0.084 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at 
> 

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.15

[Julian Reschke]

On 2016-12-08 13:04, Davide Giannella wrote:

...


[X] +1 Release this package as Apache Jackrabbit Oak 1.5.15

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.15

[Davide Giannella]

[X] +1 Release this package as Apache Jackrabbit Oak 1.5.15

D.

[jira] [Assigned] (JCRVLT-144) Unable to perform checkouts with vlt > 3.1.26

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-144:
---

Assignee: Tobias Bocanegra

> Unable to perform checkouts with vlt > 3.1.26
> -
>
> Key: JCRVLT-144
> URL: https://issues.apache.org/jira/browse/JCRVLT-144
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.1.28, 3.1.30
>Reporter: Radu Cotescu
>Assignee: Tobias Bocanegra
>
> When trying to perform a {{vlt co}} with {{vlt}} > 3.1.26 I get the following 
> error message:
> {noformat}
> vlt co --force http://localhost:4502
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; 
> support was removed in 8.0
> Checkout http://localhost:4502/crx/server/-/jcr:root/ with local files using 
> root at [...]/content/src/content/jcr_root
> Connecting via JCR remoting to http://localhost:4502/crx/server
> [ERROR] checkout: org.apache.jackrabbit.vault.vlt.VltException: Unable to 
> mount filesystem
> caused by: javax.jcr.lock.LockException: Precondition Failed
>   caused by: org.apache.jackrabbit.webdav.DavException: Precondition Failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-3995:

Fix Version/s: 2.14
   2.13.6

> occasional test failure in 
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
> 
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.13.0
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 2.13.6, 2.14
>
> Attachments: JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
>   Time elapsed: 0.084 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at 
> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest.testAddingFourAccessControlEntries(AccessControlManagerImplTest.java:159)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.15

[Marcel Reutegger]

Hi,

On 08/12/16 13:04, Davide Giannella wrote:
> Please vote on releasing this package as Apache Jackrabbit Oak 1.5.15.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.

All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.5.15

Regards
  Marcel

[jira] [Created] (JCRVLT-144) Unable to perform checkouts with vlt > 3.1.26

[Radu Cotescu (JIRA)]

Radu Cotescu created JCRVLT-144:
---

 Summary: Unable to perform checkouts with vlt > 3.1.26
 Key: JCRVLT-144
 URL: https://issues.apache.org/jira/browse/JCRVLT-144
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: vlt
Affects Versions: 3.1.30, 3.1.28
Reporter: Radu Cotescu


When trying to perform a {{vlt co}} with {{vlt}} > 3.1.26 I get the following 
error message:

{noformat}
vlt co --force http://localhost:4502
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; 
support was removed in 8.0
Checkout http://localhost:4502/crx/server/-/jcr:root/ with local files using 
root at [...]/content/src/content/jcr_root
Connecting via JCR remoting to http://localhost:4502/crx/server
[ERROR] checkout: org.apache.jackrabbit.vault.vlt.VltException: Unable to mount 
filesystem
caused by: javax.jcr.lock.LockException: Precondition Failed
  caused by: org.apache.jackrabbit.webdav.DavException: Precondition Failed
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-4077) disable Jackrabbit VFS Extension (?)

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4077:
---

 Summary: disable Jackrabbit VFS Extension (?)
 Key: JCR-4077
 URL: https://issues.apache.org/jira/browse/JCR-4077
 Project: Jackrabbit Content Repository
  Issue Type: Sub-task
  Components: jackrabbit-vfs-ext
Affects Versions: 2.13.6
Reporter: Julian Reschke
 Fix For: 2.14


Switching to the new httpclient code will break jackrabbit-vfs-ext, which has a 
dependency on the older version.

(Suggestions about how to deal with this welcome)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.15

[Vikas Saurabh]

[X] +1 Release this package as Apache Jackrabbit Oak 1.5.15

ALL CHECKS OK

Thanks,
Vikas

[VOTE] Release Apache Jackrabbit Oak 1.5.15

[Davide Giannella]

A candidate for the Jackrabbit Oak 1.5.15 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.5.15/

The release candidate is a zip archive of the sources in:

   
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.5.15/

The SHA1 checksum of the archive is
59e6311e9d9e754b417119aaebb5de97efcd81ad.

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.15
59e6311e9d9e754b417119aaebb5de97efcd81ad

Please vote on releasing this package as Apache Jackrabbit Oak 1.5.15.
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.15
[ ] -1 Do not release this package because...

Davide

[jira] [Commented] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()

[Alfusainey Jallow (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15731887#comment-15731887
 ] 

Alfusainey Jallow commented on JCR-3995:


[~reschke] kindly look at the attached patch. the build (mvn clean install 
-PintegrationTesting) passes on my side. this time, i try to remove all 
policies persisted at the testRoot node after the execution of every test unit.

> occasional test failure in 
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
> 
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.13.0
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
>   Time elapsed: 0.084 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at 
> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest.testAddingFourAccessControlEntries(AccessControlManagerImplTest.java:159)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-3995) occasional test failure in AccessControlManagerImplTest.testAddingFourAccessControlEntries()

[Alfusainey Jallow (JIRA)]

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

Alfusainey Jallow updated JCR-3995:
---
Attachment: JCR-3995.patch

> occasional test failure in 
> AccessControlManagerImplTest.testAddingFourAccessControlEntries()
> 
>
> Key: JCR-3995
> URL: https://issues.apache.org/jira/browse/JCR-3995
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.13.0
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: JCR-3995.patch
>
>
> Need to run with {{-PintegrationTesting}}, seen in jackrabbit-jcr2dav:
> {noformat}
> testAddingFourAccessControlEntries(org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest)
>   Time elapsed: 0.084 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at 
> org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlManagerImplTest.testAddingFourAccessControlEntries(AccessControlManagerImplTest.java:159)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Restrict matrix tasks to specific nodes

[Francesco Mari]

Hi,

I recently discovered that some of the tests run by the Apache
Jackrabbit Oak Matrix job [1] consistently fail when matrix tasks are
scheduled on one of the nodes labelled "beam". I documented the
failures in this issue [2].

I would like to schedule the matrix tasks to run on specific nodes or,
at least, not to run on the faulty ones. What is the best way to
achieve this?

Thanks,

Francesco

[1]: https://builds.apache.org/view/All/job/Apache%20Jackrabbit%20Oak%20matrix/
[2]: https://issues.apache.org/jira/browse/OAK-5017

Re: Frequent failures in standby test

[Francesco Mari]

In the meantime, I configured those tests not to run when they are
scheduled under a "beam" node. I will send a separate mail to builds@
and put oak-dev@ in CC.

2016-12-08 11:23 GMT+01:00 Robert Munteanu :
> Hi,
>
> On Thu, 2016-12-08 at 10:01 +0100, Francesco Mari wrote:
>> I analysed the latest builds to figure out what's going on with some
>> tests related to Cold Standby. It seems that the problem is
>> restricted
>> to some Jenkins nodes - see [1] for more details. Can we configure
>> the
>> Jenkins job not to run on nodes labelled "beam"?
>>
>> [1]: https://issues.apache.org/jira/browse/OAK-
>> 5017?focusedCommentId=15731590=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-15731590
>
> The job is configured to only run on 'ubuntu' nodes, but it seems that
> this restriction is not taken into account. The following Jenkins issue
> might be related
>
>   https://issues.jenkins-ci.org/browse/JENKINS-23459
>
> Perhaps a question better suited to builds@ ? They would be interested
> in proper resource utilisation.
>
> Robert
>
>>
>> 2016-11-25 13:25 GMT+01:00 Francesco Mari :
>> > Every failure in build 1298 is due to "java.net.BindException:
>> > Address
>> > already in use". According to the build log, the port wasn't bound
>> > by
>> > a server started during a test. The first failing test
>> > (ExternalSharedStoreIT) was also the first test in the build to
>> > start
>> > a server. The issue persisted for some tests (the whole range of
>> > tests
>> > in ExternalSharedStoreIT and the first test in FailoverSslTestIT),
>> > so
>> > I can't deduce any random behaviour. Once the port (presumingly
>> > bound
>> > to an external process) was released, every other integration test
>> > worked without any problem.
>> >
>> > 2016-11-25 5:38 GMT+01:00 Chetan Mehrotra > > m>:
>> > > Per https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20mat
>> > > rix/1298/
>> > > the test again failed but mostly on Jdk 1.7. The test on Jdk 1.8
>> > > looks
>> > > like passed.
>> > > Chetan Mehrotra
>> > >
>> > >
>> > > On Tue, Nov 22, 2016 at 12:48 PM, Chetan Mehrotra
>> > >  wrote:
>> > > > They are from oak-segment-tar. See
>> > > > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matri
>> > > > x/1295/#showFailuresLink
>> > > > Chetan Mehrotra
>> > > >
>> > > >
>> > > > On Tue, Nov 22, 2016 at 12:42 PM, Francesco Mari
>> > > >  wrote:
>> > > > > Are those from oak-tarmk-standby or oak-segment-tar?
>> > > > >
>> > > > > 2016-11-22 6:11 GMT+01:00 Chetan Mehrotra > > > > > ail.com>:
>> > > > > > Hi Team,
>> > > > > >
>> > > > > > Since last 4-6 builds I am seeing a recurring failure of
>> > > > > > few test in
>> > > > > > standby module
>> > > > > >
>> > > > > > * FailoverIPRangeIT
>> > > > > > * ExternalPrivateStoreIT
>> > > > > > * StandbyTestIT
>> > > > > >
>> > > > > > Probably something to be looked into
>> > > > > >
>> > > > > > Chetan Mehrotra
>

Re: RIP Apache Jenkins!?

[Robert Munteanu]

On Thu, 2016-12-08 at 10:46 +0100, Julian Reschke wrote:
> On 2016-12-07 12:21, Michael Dürig wrote:
> > 
> > In a F2F discussion we agreed to pay more attention to test
> > failures on
> > the Apache Jenkins instance and make an effort to turn it green:
> > 
> > - tests that are constantly failing and also fail on a local
> > checkout
> > should be marked @Ignored along with an issue reference and an bug
> > report in Jira.
> > 
> > - tests that only fail on Jenkins should be marked as such through
> > the
> > CIHelpers facility
> > 
> > In the meanwhile I tried to configure the Jenkins Jira plugin so it
> > would automatically file Jira issues for failures. This didn't seem
> > to
> > successful as the last failing build didn't show up in the Oak
> > Jira.
> > There is no indications of anything going wrong in the build logs
> > neither though. Anyone who wants to take this up, be my guest.
> > 
> > Michael
> 
> +1
> 
> FWIW; we have way too many tests that happen to fail "sometimes".
> The 
> following just happened twice to me when running integration tests:
> 
> Failed tests: 
> externalAddOffline(org.apache.jackrabbit.oak.plugins.blob.datastore.B
> lobIdTrackerTest): 
> expected:<1006> but was:<1001>

There is a plug-in named 'Test results analyser' [1] installed on the
ASF Jenkins instance which exposes test execution results over a number
of jobs.

We have it enabled for Sling and you can see some of the flaky tests
'in action' at

  https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-ins
taller-it-1.8/test_results_analyzer/

You might want to enable it to track how flaky tests really are.

Robert

[1]: https://wiki.jenkins-ci.org/display/JENKINS/Test+Results+Analyzer+
Plugin

Re: Frequent failures in standby test

[Robert Munteanu]

Hi,

On Thu, 2016-12-08 at 10:01 +0100, Francesco Mari wrote:
> I analysed the latest builds to figure out what's going on with some
> tests related to Cold Standby. It seems that the problem is
> restricted
> to some Jenkins nodes - see [1] for more details. Can we configure
> the
> Jenkins job not to run on nodes labelled "beam"?
> 
> [1]: https://issues.apache.org/jira/browse/OAK-
> 5017?focusedCommentId=15731590=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15731590

The job is configured to only run on 'ubuntu' nodes, but it seems that
this restriction is not taken into account. The following Jenkins issue
might be related

  https://issues.jenkins-ci.org/browse/JENKINS-23459

Perhaps a question better suited to builds@ ? They would be interested
in proper resource utilisation.

Robert

> 
> 2016-11-25 13:25 GMT+01:00 Francesco Mari :
> > Every failure in build 1298 is due to "java.net.BindException:
> > Address
> > already in use". According to the build log, the port wasn't bound
> > by
> > a server started during a test. The first failing test
> > (ExternalSharedStoreIT) was also the first test in the build to
> > start
> > a server. The issue persisted for some tests (the whole range of
> > tests
> > in ExternalSharedStoreIT and the first test in FailoverSslTestIT),
> > so
> > I can't deduce any random behaviour. Once the port (presumingly
> > bound
> > to an external process) was released, every other integration test
> > worked without any problem.
> > 
> > 2016-11-25 5:38 GMT+01:00 Chetan Mehrotra  > m>:
> > > Per https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20mat
> > > rix/1298/
> > > the test again failed but mostly on Jdk 1.7. The test on Jdk 1.8
> > > looks
> > > like passed.
> > > Chetan Mehrotra
> > > 
> > > 
> > > On Tue, Nov 22, 2016 at 12:48 PM, Chetan Mehrotra
> > >  wrote:
> > > > They are from oak-segment-tar. See
> > > > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matri
> > > > x/1295/#showFailuresLink
> > > > Chetan Mehrotra
> > > > 
> > > > 
> > > > On Tue, Nov 22, 2016 at 12:42 PM, Francesco Mari
> > > >  wrote:
> > > > > Are those from oak-tarmk-standby or oak-segment-tar?
> > > > > 
> > > > > 2016-11-22 6:11 GMT+01:00 Chetan Mehrotra  > > > > ail.com>:
> > > > > > Hi Team,
> > > > > > 
> > > > > > Since last 4-6 builds I am seeing a recurring failure of
> > > > > > few test in
> > > > > > standby module
> > > > > > 
> > > > > > * FailoverIPRangeIT
> > > > > > * ExternalPrivateStoreIT
> > > > > > * StandbyTestIT
> > > > > > 
> > > > > > Probably something to be looked into
> > > > > > 
> > > > > > Chetan Mehrotra

Re: RIP Apache Jenkins!?

[Amit Jain]

>> Failed tests: externalAddOffline(org.apache.
jackrabbit.oak.plugins.blob.datastore.BlobIdTrackerTest): expected:<1006>
but was:<1001>
Was added yesterdaytaking a look. Will Ignore it meantime.

Thanks
Amit

On Thu, Dec 8, 2016 at 3:16 PM, Julian Reschke 
wrote:

> On 2016-12-07 12:21, Michael Dürig wrote:
>
>>
>> In a F2F discussion we agreed to pay more attention to test failures on
>> the Apache Jenkins instance and make an effort to turn it green:
>>
>> - tests that are constantly failing and also fail on a local checkout
>> should be marked @Ignored along with an issue reference and an bug
>> report in Jira.
>>
>> - tests that only fail on Jenkins should be marked as such through the
>> CIHelpers facility
>>
>> In the meanwhile I tried to configure the Jenkins Jira plugin so it
>> would automatically file Jira issues for failures. This didn't seem to
>> successful as the last failing build didn't show up in the Oak Jira.
>> There is no indications of anything going wrong in the build logs
>> neither though. Anyone who wants to take this up, be my guest.
>>
>> Michael
>>
>
> +1
>
> FWIW; we have way too many tests that happen to fail "sometimes". The
> following just happened twice to me when running integration tests:
>
> Failed tests: 
> externalAddOffline(org.apache.jackrabbit.oak.plugins.blob.datastore.BlobIdTrackerTest):
> expected:<1006> but was:<1001>
>
> Best regards, Julian
>
>

Re: RIP Apache Jenkins!?

[Julian Reschke]

On 2016-12-07 12:21, Michael Dürig wrote:


In a F2F discussion we agreed to pay more attention to test failures on
the Apache Jenkins instance and make an effort to turn it green:

- tests that are constantly failing and also fail on a local checkout
should be marked @Ignored along with an issue reference and an bug
report in Jira.

- tests that only fail on Jenkins should be marked as such through the
CIHelpers facility

In the meanwhile I tried to configure the Jenkins Jira plugin so it
would automatically file Jira issues for failures. This didn't seem to
successful as the last failing build didn't show up in the Oak Jira.
There is no indications of anything going wrong in the build logs
neither though. Anyone who wants to take this up, be my guest.

Michael


+1

FWIW; we have way too many tests that happen to fail "sometimes". The 
following just happened twice to me when running integration tests:


Failed tests: 
externalAddOffline(org.apache.jackrabbit.oak.plugins.blob.datastore.BlobIdTrackerTest): 
expected:<1006> but was:<1001>


Best regards, Julian

Re: Frequent failures in standby test

[Francesco Mari]

I analysed the latest builds to figure out what's going on with some
tests related to Cold Standby. It seems that the problem is restricted
to some Jenkins nodes - see [1] for more details. Can we configure the
Jenkins job not to run on nodes labelled "beam"?

[1]: 
https://issues.apache.org/jira/browse/OAK-5017?focusedCommentId=15731590=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15731590

2016-11-25 13:25 GMT+01:00 Francesco Mari :
> Every failure in build 1298 is due to "java.net.BindException: Address
> already in use". According to the build log, the port wasn't bound by
> a server started during a test. The first failing test
> (ExternalSharedStoreIT) was also the first test in the build to start
> a server. The issue persisted for some tests (the whole range of tests
> in ExternalSharedStoreIT and the first test in FailoverSslTestIT), so
> I can't deduce any random behaviour. Once the port (presumingly bound
> to an external process) was released, every other integration test
> worked without any problem.
>
> 2016-11-25 5:38 GMT+01:00 Chetan Mehrotra :
>> Per https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1298/
>> the test again failed but mostly on Jdk 1.7. The test on Jdk 1.8 looks
>> like passed.
>> Chetan Mehrotra
>>
>>
>> On Tue, Nov 22, 2016 at 12:48 PM, Chetan Mehrotra
>>  wrote:
>>> They are from oak-segment-tar. See
>>> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1295/#showFailuresLink
>>> Chetan Mehrotra
>>>
>>>
>>> On Tue, Nov 22, 2016 at 12:42 PM, Francesco Mari
>>>  wrote:
 Are those from oak-tarmk-standby or oak-segment-tar?

 2016-11-22 6:11 GMT+01:00 Chetan Mehrotra :
> Hi Team,
>
> Since last 4-6 builds I am seeing a recurring failure of few test in
> standby module
>
> * FailoverIPRangeIT
> * ExternalPrivateStoreIT
> * StandbyTestIT
>
> Probably something to be looked into
>
> Chetan Mehrotra