[
https://issues.apache.org/jira/browse/DERBY-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632125#action_12632125
]
Kristian Waagan commented on DERBY-3878:
----------------------------------------
Workaround
==========
As posted by Jørgen on derby-user:
"I think you'll have to shutdown the slave Derby instance before restarting
replication until this bug has been fixed. "
(
http://www.nabble.com/Stopping---(Re)Starting-Slave-within-replication-td19496642.html
)
> Replication: stopSlave does not close serversocket when master has crashed.
> ---------------------------------------------------------------------------
>
> Key: DERBY-3878
> URL: https://issues.apache.org/jira/browse/DERBY-3878
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.2.0
> Reporter: Jørgen Løland
> Attachments: d3878-suggested-fix.diff
>
>
> The stopSlave command (connection URL attribute) fails to close the
> ServerSocket when called after master database has crashed. Because of this,
> the same Derby instance cannot later start a slave on the same port.
> The problem is in ReplicationMessageReceive#tearDown and
> SocketConnection#tearDown:
> SC#tearDown:
> When objOutputStream is closed, the stream's flush method is called. Flush
> throws an exception, and socket.close is not called.
> RMR#tearDown:
> When socketCon.teardown throws an exception, serverSocket.close is not called.
> Suggested fix: add try/catch/finally blocks so that vital code (socket.close
> and serverSocket.close) is always called.
> Note that the stop slave command can also come from the master (if stopMaster
> connection URL is called), in which case this bug will not materialize.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
