You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2008/09/16 14:36:44 UTC

[jira] Updated: (DERBY-3878) Replication: stopSlave does not close serversocket when master has crashed.

     [ https://issues.apache.org/jira/browse/DERBY-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-3878:
--------------------------------------

    Attachment: d3878-suggested-fix.diff

I tried the fix you suggested (attached as d3878-suggested-fix.diff) and it seems to fix the problem in my environment. Without the fix, I can successfully stop the slave after the master has crashed, but I cannot restart the slave because the port is still in use. With the fix, I can restart the slave on the same port.

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