[
https://issues.apache.org/jira/browse/DERBY-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634815#action_12634815
]
Knut Anders Hatlen commented on DERBY-3878:
-------------------------------------------
Derbyall and suites.All ran cleanly with the suggested fix. I plan to add some
comments to the patch and commit it. We should also have a regression test for
this bug. I haven't looked at the replication tests before, so any advice would
be appreciated.
> 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
> Assignee: Knut Anders Hatlen
> 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.
