db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3358) After an incorrect(unsuccesfull) startMaster comand, further correct startMaster attempts also fail.
Date Wed, 27 Feb 2008 06:04:51 GMT

    [ 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.


Mime
View raw message