[
https://issues.apache.org/jira/browse/DERBY-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572798#action_12572798
]
V.Narayanan commented on DERBY-3358:
------------------------------------
>I feel the comments regarding the testing of active in
>startMaster, stopMaster, and startFailover is a bit confusing.
>It seems to be more a documentation of the change that is made
>than of the resulting code, and I fear that it may confuse
>people who do not know the history of the code.
General view (my thinking when I wrote the comments)
I wrote the comments from the point of view of a person who
would try to understand this code while single stepping using
an IDE.
I have also tried to explain why I tried to write the methods the
way I have in the individual methods.
I would really appreciate it if you could give an example for just
one method, re-wording the comments in a way you think is right
so that I can follow the same on the other methods.
comments in startMaster
>//Check if the master has already been started. It is wrong to attempt
>//startMaster on a already running master since the start parameters
>//can vary with each start and the question of idempotence is not
>//applicable here (unlike stopMaster).
I was trying to say that taking a connection with the startMaster
attribute repeatedly should throw an exception. Can you please give
an example as to what would be an appropriating re-wording here?
Was the problem with the usage of the word idempotent? Was the mention
of the start parameters a implementation specific thing that should
be avoided?
comments in stopMaster
>//This can happen only if the replication master module was
>//loaded previously and was later stopped. If replication was
>//never loaded an exception would be thrown because the master
>//factory module will not be found. This makes the stopMaster
>//operation idempotent, will keep returning successfully when
>//repeatedly called on an already started replication instance.
This comment explains what would happen if a bootServiceModule
was called and was later stopped by calling a stopMaster or the
boot itself fails. active becomes false.
I can remove this comment if you think it is inappropriate but
I think it serves to explain why I made the method return harmlessly
when it is called repeatedly
startFailover
>//It is not correct to stop the master and then attempt a failover.
>//The control would come here because the master module is already
>//loaded and a findService for the master module will not fail. But
>//since this module has been stopped failover does not suceed.
I guess you are suggesting that usage of words like findService which is
code specific is not right?
But I thought anyone who would follow the code while sigle-stepping using
an IDE would find this useful because it would explain when the control
would come here
> 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
> Attachments: Derby3358.diff, Derby3358.stat
>
>
> 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.
