[
https://issues.apache.org/jira/browse/DERBY-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571983#action_12571983
]
V.Narayanan commented on DERBY-3358:
------------------------------------
There seems to be no satisfactory solution to unbooting a module.
Hence I am going ahead with the workaround suggested by me earlier.
Please find below the workaround implementation explained in more detail.
Implementation description
---------------------------
The properties object that is passed to the boot method can no longer
be used to initialize the MasterController startup parameters. This needs
to be moved to the startMaster method.
A successful startup should be recorded by a boolean variable (active).
Each of the methods (other than startMaster) in the MasterController that form
the interface to this module
* stopMaster
* startFailover
should check for the boolean variable active. If it is false they should throw
an exception stating that
the master module is not active.
active should be set to false in
* stopMaster and
* when startMaster fails.
A few observations
------------------
stopMaster is called from printStackAndStopMaster. printStackAndStopMaster is
specifically a method
that logs log shipper exceptions. So doing a logShipper.flushBuffer() in
stopMaster does not seem logical.
I will wait till later today to raise a separate JIRA for this. I do not want
to fix this issue as part of this JIRA.
A possible fix for the above would be to separate the flushBuffer and the
stopMaster operations.
> After an incorrect(unsuccesfull) startMaster comand, further correct
> startMaster attempts also fail.
> ----------------------------------------------------------------------------------------------------
>
> Key: DERBY-3358
> URL: https://issues.apache.org/jira/browse/DERBY-3358
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.0.0
> Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b
> Reporter: Ole Solberg
> Assignee: V.Narayanan
>
> Slave and master servers started.
> startSlave:
> CONNECT
> 'jdbc:derby://atum11:9999/test;startSlave=true;slaveHost=atum11;slavePort=8989';
> ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC:
> Replication slave mode started successfully for database 'test'. Connection
> refused because the database is in replication slave mode.
> startMaster without specifying slavePort - will use default?
> CONNECT 'jdbc:derby://atum11:8888/test;startMaster=true;slaveHost=atum11';
> ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC:
> nullXRE04
> master derby.log:
> 2008-01-29 10:02:53.097 GMT:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.4.0.0 alpha - (615841M): instance c013800d-0117-c4fb-9156-000003bf6570
> on database directory
> /export/home/tmp/os136789/Replication_common_Trunk/master/test
> Database Class Loader started - derby.database.classpath=''
> 2008-01-29 10:02:53.256 GMT Thread[DRDAConnThread_2,5,main] (XID = 419),
> (SESSIONID = 0), (DATABASE = test), (DRDAID = {1}), Cleanup action starting
> java.sql.SQLException: Could not establish a connection to the peer of the
> replicated database 'null'.
> .
> .
> Cleanup action completed
> 2008-01-29 10:02:53.260 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
> test), (DRDAID = {1}), Could not establish a connection to the peer of the
> replicated database 'null'.
> startMaster specyfying slavePort:
> CONNECT
> 'jdbc:derby://atum11:8888/test;startMaster=true;slaveHost=atum11;slavePort=8989';
> ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC:
> nullXRE04
> master derby.log:
> 2008-01-29 10:03:38.201 GMT Thread[DRDAConnThread_2,5,main] (XID = 420),
> (SESSIONID = 1), (DATABASE = test), (DRDAID = {2}), Cleanup action starting
> java.sql.SQLException: Could not establish a connection to the peer of the
> replicated database 'null'.
> .
> .
> Cleanup action completed
> 2008-01-29 10:03:38.205 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
> test), (DRDAID = {2}), Could not establish a connection to the peer of the
> replicated database 'null'.
> Additional observation/comment:
> ----------------------------------------
> It would be helpful for debugging if slaveHost and slavePort were written in
> error messages and into derby.log.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
