Details
-
Test
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
Discovery Impl 1.2.2, Discovery Base 1.1.0
-
None
Description
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)
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:
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
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