db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-4269) Failover did not succeed in 2 min.: testReplication_Local_3_p6_autocommit_OK
Date Thu, 07 Jun 2012 21:52:23 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291349#comment-13291349

Dag H. Wanvik commented on DERBY-4269:

In SlaveDataBase, the variable "inReplicationSlaveMode" holds the state. The error message
08004.C.7 ("Connection refused to database '{0}' because it is in replication slave mode")
i only every issued in two locations, both inside SlaveDataBase, in methods "setupConnection"
and "getAuthenticationService".

In both cases, they test the variable inReplicationSlaveMode.  Looking at the booting (recovery)
thread, the variable is reset to false ca line 317, inside the thread SlaveDatabaseBootThread:

 try {
   bootBasicDatabase(create, params); // will be blocked

   // if we get here, failover has been called and the
   // database can now be connected to
   inReplicationSlaveMode = false; 
 } catch (StandardException se) {
   // We get here when SlaveController#stopSlave has been
   // called, or if a fatal exception has been thrown.

Now, the thread is gone, but in our cae the variable is still true, so I believe the boot
must have thrown a (runtime?) exception for this to occur. Notice we only catch StandardException,
but any runetime exception would go unnoticed and the thread would terminate.
I'll try to instrument this code to log any exceptions on derby.log before the thread dies.
> 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:
>         Environment: OS:
> Microsoft© Windows VistaT Ultimate - 6.0.6001 Service Pack 1 - WindowsNT 0 6
> JVM:
> Sun Microsystems Inc. 
> 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
>            Priority: Minor
>              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.stat, db_master-derby.log, db_slave-derby.log.gz,
> Failover did not succeed.
> 2) testReplication_Local_3_p6_autocommit_OK(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p6)junit.framework.AssertionFailedError:
Failover did not succeed.
> 	at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:270)
> 	at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p6.derby_3896(ReplicationRun_Local_3_p6.java:200)
> 	at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p6.testReplication_Local_3_p6_autocommit_OK(ReplicationRun_Local_3_p6.java:86)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:106)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> See http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/testlog/vista-64/782274-suitesAll_diff.txt

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


View raw message