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:28:10 UTC

[jira] [Updated] (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:all-tabpanel ]

Stefan Egli updated SLING-5313:
-------------------------------
    Attachment: faultyNewVote

Attaching [^faultyNewVote] which is a log excerpt containing the phase where a new vote is created and which contains the warns pointed out in this ticket

> 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
>
>         Attachments: faultyNewVote
>
>
> 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)