You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2015/11/19 10:27:11 UTC

[jira] [Comment Edited] (SLING-5313) ClusterTest.testAdditionalInstance failure due to using old jackrabbit version

    [ https://issues.apache.org/jira/browse/SLING-5313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013216#comment-15013216 ] 

Stefan Egli edited comment on SLING-5313 at 11/19/15 9:27 AM:
--------------------------------------------------------------

* refined some logging for this kind of test failures in rev 1715133
* plus upped the used jcr-commons version to 2.10.1 (from 2.2.9 which is referenced by sling.commons.testing) in rev 1715134

(once discovery tests are 100% stable we can look into upping sling.commons.testing itself probably - but that might have wider implications)


was (Author: egli):
* refined some logging for this kind of test failures in rev 
* plus upped the used jcr-commons version to 2.10.1 (from 2.2.9 which is referenced by sling.commons.testing) in rev 1715134

(once discovery tests are 100% stable we can look into upping sling.commons.testing itself probably - but that might have wider implications)

> ClusterTest.testAdditionalInstance failure due to using old jackrabbit version
> ------------------------------------------------------------------------------
>
>                 Key: SLING-5313
>                 URL: https://issues.apache.org/jira/browse/SLING-5313
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Discovery Impl 1.2.2, Discovery Base 1.1.0
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>            Priority: Minor
>             Fix For: Discovery Base 1.1.2, Discovery Impl 1.2.4
>
>
> failed on jenkins: https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/2040/testReport/org.apache.sling.discovery.impl.cluster/ClusterTest/testAdditionalInstance/
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.apache.sling.discovery.base.its.AbstractClusterTest.testAdditionalInstance(AbstractClusterTest.java:1317)
> {code}
> while the problem as it turns out was, that one instance votes around the same time the new voting is committed - then the following warnings show up:
> {code}
> 18.11.2015 17:34:05.734 *WARN * [main] ItemStateReferenceCache: overwriting cached entry 1a023c37-3d63-4a15-a875-2a321b975e73
> 18.11.2015 17:34:05.734 *WARN * [main] ItemStateReferenceCache: overwriting cached entry 555a8ba4-cd36-4eed-b1b4-b350a2abdf2c
> 18.11.2015 17:34:05.734 *WARN * [main] ItemStateReferenceCache: overwriting cached entry 3b86f1ef-daa1-4cce-a4b5-5d76e212719e
> 18.11.2015 17:34:05.734 *WARN * [main] ItemStateReferenceCache: overwriting cached entry 83196e26-f741-445e-b111-2880a8cd9bbf
> {code}
> and that instance's yes vote is never seen by the other instance (session in the same vm). Ie although this is happening all in the same VM, one session's changes do not propagate to the other session. This seems to be due/related to the above warn.
> Looking at the used jackrabbit version it turns out sling.commons.testing still uses jcr-commons 2.2.9 - while we should probably use something much newer like 2.10



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