Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <32386080.1191312291552.JavaMail.jira@brutus>
Date: Tue, 2 Oct 2007 01:04:51 -0700 (PDT)
From: "V.Narayanan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3064) Implement the LogShipper that will
 enable the shipping of Log records from the master to the slave
In-Reply-To: <13994899.1189420769956.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

V.Narayanan updated DERBY-3064:
-------------------------------

    Attachment: LogShipperImpl_v4.stat
                LogShipperImpl_v4.diff

Thank you for the comments on the patch Oystein. I have addressed all the
issues pointed out. Some explanation for the changes made follows.

> AsynchronousLogShipper, unused import: SQLState

In order to address your comment related to NoSuchElementException I am
throwing a StandardException with SQLState as SQLState.REPLICATION_FATAL_ERROR.
I therefore have retained this import.

>"when the shipper is informed to perform its periodic shipping
>also." I feel this sentence is a bit unclear. What does is mean
>to be "informed to perform its periodic shipping"? 

I meant when a forceFlush wakes up the periodic shipping thread. I have however
rephrased it to say

"  The log shipping happens at the configured shipping intervals unless a
   force flush happens, which triggers periodic shipping also since there
   will still be more log to send after the forceFlush has sent one chunk. "

>AsynchronousLogShipper#shipALogChunk/forceFlush: I am not sure
>that it is a good idea to call handleException when you are not in
>the log shipping thread. In that case, one might as well just let
>the exception go up to the MasterController directly. I would
>also think it is the master controller that should decide whether
>or not to reconnect, not the log shipper on its own. With respect
>to NoSuchElementException, I think you have better knowledge of
>the context in which it is happening here than the
>MasterController will have, and it might be a good idea that the
>log shipper decides how to handle it. Since it will occur if you
>do not get any data even if next() return true, something fatal
>must have happened, and I guess you might as well report back a
>fatal replication error. 

I have changed the shipALogChunk() method to throw its exceptions so that
the run() and the forceFlush() may handle them apropos.

I now catch the NoSuchElementException and wrap it in a StandardException
with a SQLState as SQLState.REPLICATION_FATAL_ERROR.

The IOException caused by a connection failure is also thrown, no reconnect
is attempted.

forceFlush() throws all its exceptions to master controller. I am wrapping the
IOException obtained while calling shipALogChunk in a StandardException since
its signature in LogShipper mandates that a StandardException is what is throw.

run() calls handleExceptions.

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


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.