[
https://issues.apache.org/jira/browse/DERBY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538513
]
Knut Anders Hatlen commented on DERBY-3064:
-------------------------------------------
> I have overcome this by doing
>
> failedChunk = (mesg==null) ? failedChunk : mesg;
I think this would be clearer if written as
if (mesg != null} {
failedChunk = mesg;
}
Then it's clearer that nothing happens if mesg==null.
> I have interrupted the log shipper thread and consequently removed
> the stopShipping check from the run() method. I instead have
> introduced a while(true) loop. I have however retained the
> stopShipping check inorder to ensure that a forceFlush call after
> stopreplication does not succeed.
I don't think you can remove the stopShipping check just because the
thread is interrupted. An interrupt does not stop the thread, but
blocking I/O operations will fail, and calls to sleep() or wait()
throw InterruptedException. As far as I can see, run() still silently
ignores InterruptedException, so the loop will just continue.
Anyway, I'm not sure we should rely on Thread.interrupt() to stop a
thread since it is hard to predict the state of the thread after it
has been interrupted. In general, I think wait()/notify() is a better
mechanism than sleep()/interrupt().
> b) InterruptedExceptions are normally trapped since they occur when
> some code intentionally interrupts the thread.
I think the normal way to handle InterruptedException in Derby is
catch (InterruptedException ie) {
throw StandardException.interrupt(ie);
}
> I initially thought of reporting IOExceptions here, but IOExceptions
> cause setupConnection to return false and a next reconnect is
> attempted in half a second. Reporting this failure in log would
> cause a IOException to be printed in the log every half a
> second. Would'nt this amount to flooding the log? All these
> IOEXceptions being registered would contain the same information
> stating a socket connection exception. So I was afraid that it would
> contain the same information being repeated too many times.
If this is always a socket connection exception, could the catch
clause be narrowed down to java.net.ConnectException instead of
java.io.Exception?
Also, should we give up and fail gracefully after a certain number of
retries?
> Implement the LogShipper that will enable the shipping of Log records from
> the master to the slave
> --------------------------------------------------------------------------------------------------
>
> Key: DERBY-3064
> URL: https://issues.apache.org/jira/browse/DERBY-3064
> Project: Derby
> Issue Type: Sub-task
> Reporter: V.Narayanan
> Assignee: V.Narayanan
> Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat,
> LogShipperImpl_v2.diff, LogShipperImpl_v2.stat, LogShipperImpl_v3.diff,
> LogShipperImpl_v3.stat, LogShipperImpl_v4.diff, LogShipperImpl_v4.stat,
> LogShipperImpl_v5.diff, LogShipperImpl_v5.stat,
> LogShipperIntegration_v1.diff, LogShipperIntegration_v1.stat,
> LogShipperIntegration_v2.diff, LogShipperIntegration_v2.stat
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
