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-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave
Date Mon, 29 Oct 2007 14:54:51 GMT

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


Mime
View raw message