Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 18 Jun 2012 16:29:44 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <1950009624.25456.1340036984199.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Updated] (DERBY-4269) Failover did not succeed in 2 min.:
 testReplication_Local_3_p6_autocommit_OK
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/DERBY-4269?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-4269:
---------------------------------

    Attachment: derby-4269-explicit-synch-2.diff

Yes, apparently I did. Here it is for completeness.

Unfortunately, explicit synchronization breaks other replication tests. The=
 new extra waiting in "verifySuccessfulboot" makes the boot of the slavedat=
abase (minus the actual fail-over part to make it a new master) incomplete =
until fail-over time, cf. the call to startPersistentService mentioned abov=
e will now wait longer.

This makes other connection attempts to the slave hang (the service isn't s=
tarted, so the new thread tries to start it again), whereas previously a ne=
w thread returned an error indicating that the slave was still in slave sta=
te. So, I am back to the first patch, which skips the clearing of the prope=
rties for slave databases.

               =20
> Failover did not succeed in 2 min.: testReplication_Local_3_p6_autocommit=
_OK
> -------------------------------------------------------------------------=
---
>
>                 Key: DERBY-4269
>                 URL: https://issues.apache.org/jira/browse/DERBY-4269
>             Project: Derby
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10=
.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2
>         Environment: OS:
> Microsoft=C2=A9 Windows VistaT Ultimate - 6.0.6001 Service Pack 1 - Windo=
wsNT 0 6
> JVM:
> Sun Microsystems Inc.=20
> java version "1.4.2_16"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_16-b05)
> Java HotSpot(TM) Client VM (build 1.4.2_16-b05 mixed mode 32-bit)
>            Reporter: Ole Solberg
>            Assignee: Dag H. Wanvik
>              Labels: derby_triage10_5_2
>         Attachments: 4269-client-jstack.txt, 4269-master.txt, 4269-slave-=
jstack-before-failover.txt, 4269-slave.txt, DERBY-4269.diff, DERBY-4269.sta=
t, DERBY-4269b.diff, db_master-derby.log, db_slave-derby.log.gz, derby-4269=
-explicit-synch-2.diff, derby-4269-explicit-synch.diff, derby-4269-typo.dif=
f
>
>
> Failover did not succeed.
> 2) testReplication_Local_3_p6_autocommit_OK(org.apache.derbyTesting.funct=
ionTests.tests.replicationTests.ReplicationRun_Local_3_p6)junit.framework.A=
ssertionFailedError: Failover did not succeed.
> =09at org.apache.derbyTesting.functionTests.tests.replicationTests.Replic=
ationRun.connectPing(ReplicationRun.java:270)
> =09at org.apache.derbyTesting.functionTests.tests.replicationTests.Replic=
ationRun_Local_3_p6.derby_3896(ReplicationRun_Local_3_p6.java:200)
> =09at org.apache.derbyTesting.functionTests.tests.replicationTests.Replic=
ationRun_Local_3_p6.testReplication_Local_3_p6_autocommit_OK(ReplicationRun=
_Local_3_p6.java:86)
> =09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> =09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp=
l.java:39)
> =09at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc=
essorImpl.java:25)
> =09at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.jav=
a:106)
> =09at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> =09at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> =09at junit.extensions.TestSetup.run(TestSetup.java:25)
> See http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/testlog/vist=
a-64/782274-suitesAll_diff.txt

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira