[
https://issues.apache.org/jira/browse/DERBY-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914416#action_12914416
]
Knut Anders Hatlen commented on DERBY-4819:
-------------------------------------------
All the tests ran cleanly with remove-msgReceiver.diff, so I committed revision
1000808.
> add error reporting to ReplicationMessageTransmit.java
> MasterReceiverThread.run()
> ---------------------------------------------------------------------------------
>
> Key: DERBY-4819
> URL: https://issues.apache.org/jira/browse/DERBY-4819
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.2.0, 10.5.3.0, 10.6.1.0, 10.7.0.0
> Reporter: Kathey Marsden
> Attachments: remove-msgReceiver.diff
>
>
> While working on DERBY-4812, I noticed the following code in
> MasterReceiverThread,run().
> I am not familiar enough with replication to know if the MasterReceiverThread
> can recover from such errors. If it cannot i think it would better to have a
> clear failure at the time of the error than just a subsequent
> NullPointerException.
> As the todo says, the exceptions should at least be logged.
> Also I just noticed this one bit of code, so don't know if there are similar
> issues or TODO's elsewhere in replication code.
> } catch (SocketTimeoutException ste) {
> // ignore socket timeout on reads
> } catch (ClassNotFoundException cnfe) {
> // TODO: print problem to log
> } catch (IOException ex) {
> // TODO: print problem to log
> // If we get an exception for this socket, the log shipper
> // will clean up. Stop this thread.
> stopMessageReceiver = true;
> msgReceiver = null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
