db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4819) add error reporting to ReplicationMessageTransmit.java MasterReceiverThread.run()
Date Fri, 24 Sep 2010 08:03:33 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914376#action_12914376

Knut Anders Hatlen commented on DERBY-4819:

I agree that we should log the ClassNotFoundException and the IOException. I don't think a
SocketTimeoutException can happen here, since we haven't set a timeout on the socket, as far
as I can see. Perhaps just let the SocketTimeoutException be handled by the IOException handler?
Actually, I think it would be fine to handle the ClassNotFoundException the same way as IOException
too, since that would indicate that the slave is not well-behaved.

I didn't quite understand the comment about a clear failure at the time of the error rather
than a subsequent NPE. With a clear failure, did you have something other in mind than logging
the error? Since this is running in a separate thread, I don't think there's much else we
can do. I don't see the potential for a NPE since we break out of the loop and stop the thread
immediately after we've set msgReceiver to null.

> 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:,,,
>            Reporter: Kathey Marsden
> 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.

View raw message