[
https://issues.apache.org/jira/browse/DERBY-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701186#action_12701186
]
Dag H. Wanvik commented on DERBY-3417:
--------------------------------------
Thanks for looking at this, Knut. The approach of making them connection level
severity seems to work,
but I see many red herring from the replication regression test. It seems very
instable to me. I see anything from 0 to 3 failures
on a typical run, so it makes it hard to use to verify changes in the
replication code. I think we should put some effort into making it less
brittle. Interesting idea about getConnection.
> slave side stop in a client server mode results in SQLState printed without
> proper error message
> ------------------------------------------------------------------------------------------------
>
> Key: DERBY-3417
> URL: https://issues.apache.org/jira/browse/DERBY-3417
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.1.3
> Reporter: V.Narayanan
> Assignee: Dag H. Wanvik
>
> I tried a stopSlave on the slave side of the replication system and
> found the below
> ij> connect 'jdbc:derby://localhost:1528/replicationdb;stopSlave=true';
> ERROR XRE41: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE41, SQLERRMC: XRE41
> https://issues.apache.org/jira/browse/DERBY-3205 says
> ERROR XRE41: Replication operation 'failover' or 'stopSlave' failed because
> the connection with the master is working. Issue the 'failover' or
> 'stopMaster' operation on the master database instead.
> needs to be printed.
> I am not sure if this is a generic case for client server replication
> messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
