'.replicationTests.ReplicationRun_Local_3_p5).testReplication_Local_3_p5_DERBY_3878()' fails w/ "Could not perform operation 'stopSlave' because the database '...' has not been booted".

• Key: DERBY-4246
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Dag H. Wanvik
• Reporter: Ole Solberg
• Component/s: Replication, Test
• Affects Version/s: 10.6.0.0
• Fix Version/s: 10.5.3.0, 10.6.0.0

Environment

OS:
Microsoft© Windows VistaT Ultimate - 6.0.6001 Service Pack 1 - WindowsNT 0 6
Microsoft(R) Windows(R) Server 2003, - 5.2.3790 Service Pack 2 - WindowsNT 2 5
Microsoft Windows XP Professional - 5.1.2600 Service Pack 3 Build 2600 - CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 Cygwin

JVM:
Sun Microsystems Inc. java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22 mixed mode 32-bit)
Sun Microsystems Inc. java version "1.5.0_14" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) Java HotSpot(TM) Client VM (build 1.5.0_14-b03 mixed mode 32-bit)
Sun Microsystems Inc. java version "1.4.2_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) Java HotSpot(TM) Client VM (build 1.4.2_13-b06 mixed mode 32-bit)
Sun Microsystems Inc. java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode)
Sun Microsystems Inc. java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02) Java HotSpot(TM) Client VM (build 1.5.0_16-b02, mixed mode, sharing)

Description

testReplication_Local_3_p5_DERBY_3878(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p5)junit.framework.AssertionFailedError: Got -1 XRE11 DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE11, SQLERRMC: Could not perform operation 'stopSlave' because the database 'C:\cludev\jagtmp\autoderbyN_regression\suitesAll_7\log\db_slave\wombat' has not been booted.. Expected XRE42
at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.assertException(ReplicationRun.java:3388)
at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878(ReplicationRun_Local_3_p5.java:96)
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 e.g. http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/vista/778182-suitesAll_diff.txt

Comments

[Dag H. Wanvik]

This appears to be another instance of DERBY-4175. In that case also,
after killing the master, it takes a while for the slave to react and
close down. XRE42 is actually not the expected end state here, but the
test expects it. This will *mostly* work if the slave shutdown takes
some time, but not always, as seen in this issue. XRE42 is an
intermediate state before the slave shuts down.

What is seen in the stack trace for this issue is that the connect
attempt receives XRE11 (REPLICATION_DB_NOT_BOOTED), which is the end
state of the slave. The fix is to make the test anticipate the
intermediate states, as in the patch for DERBY-4175.

[Dag H. Wanvik]

Uploading patch derby-4246a, which factors out the stopSlave code for
both cases:

   a) the master server is running
   b) the master server is no longer running

and replaced all occurences of stop slave with a new method,
ReplicationRun.stopSlave (the old one of the same name, which was
unused, I removed).

Case b) was inlined in the fix for DERBY-4175
for ReplicationRun_Local_StateTest_part1_1 . The same fix applies here
for ReplicationRun_Local_3_p5, so I decided to factor it out. I did
the same thing for case a), sinc ethere were several instances of this
code as well. Replication suite had no errors with the patch.


 

[Knut Anders Hatlen]

This looks like a useful refactoring/cleanup. +1

While you're at it, I noticed this diff in the patch (not code added by you, just restructured):

+ } catch (SQLException se) {
+ int ec = se.getErrorCode();
+ String ss = se.getSQLState();
+ String msg = ec + " " + ss + " " + se.getMessage();
+ util.DEBUG("4. Unexpectedly failed to connect: " +
+ connectionURL + " " + msg);
+ assertTrue("Unexpectedly failed to connect: " +
+ connectionURL + " " + msg, false);

Couldn't this catch block be removed? That would simplify the code even more and also preserve the stack trace of the unexpected exception.

[Dag H. Wanvik]

Thank for looking at this, Knut.

Yes, that catch could go, but I chose to stay faithful to the way the
rest of the code is written for now (this pattern is used throughout);
it does give the additional info on the connectionURL, which one would
otherwise need to infer from the code, but I agree simplifying would
be better.

[Dag H. Wanvik]

Committed on trunk as svn 785131, resolving.

[Ole Solberg]

Not seen since commit, so closing.

[Dag H. Wanvik]

Re-opening to backport to 10.5 branch.

[Dag H. Wanvik]

Backported to 10.5 as svn 799099, closing.