[
https://issues.apache.org/jira/browse/BOOKKEEPER-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416144#comment-13416144
]
Sijie Guo edited comment on BOOKKEEPER-199 at 7/17/12 12:38 PM:
----------------------------------------------------------------
{quote}
I've just thought of separating the disk checking logic. This has sort of
useful apis which EntryLogger and LedgerCache will be using. (if we have a
usecase, will expose in admin also)
{quote}
got it. I think we don't need to separate it in a task. otherwise, I don't know
which method is used and which method is not used. you could add it in
BOOKKEEPER-345. and BOOKKEEPER-346 is based on BOOKKEEPER-345. how about doing
in this way?
{quote}
Here, I just thought of bkclient behaviours: when reading it should have logic
to find the r-o bookies and able to serve the read request. While writing these
bookies will be masked and will not be available.
{quote}
the read request is sent by reading LedgerMetadata to find available bookies.
read request doesn't look into available bookies in BookieWatcher, while write
requests looked into available bookies. so moving bookie znode from available
list would make a bookie r-o and no write requests would be sent to it again.
it made things easier.
{quote}
How about providing a separate znode like
'/ledgerrootpath/available/readonly/'
{quote}
if we added a 'readonly' znode under 'available' znode, we need to exclude it
from available list. I would suggest not to add it under 'available' znode. I
had no strong feel where to put the znode. either is OK for me.
was (Author: hustlmsp):
{quote}
I've just thought of separating the disk checking logic. This has sort of
useful apis which EntryLogger and LedgerCache will be using. (if we have a
usecase, will expose in admin also)
{quote}
got it. I think we don't need to separate it in a task. otherwise, I don't
which method is used and which method is not used. you could add it in
BOOKKEEPER-345. and BOOKKEEPER-346 is based on BOOKKEEPER-345. how about doing
in this way?
{quote}
Here, I just thought of bkclient behaviours: when reading it should have logic
to find the r-o bookies and able to serve the read request. While writing these
bookies will be masked and will not be available.
{quote}
the read request is sent by reading LedgerMetadata to find available bookies.
read request doesn't look into available bookies in BookieWatcher, while write
requests looked into available bookies. so moving bookie znode from available
list would make a bookie r-o and no write requests would be sent to it again.
it made things easier.
{quote}
How about providing a separate znode like
'/ledgerrootpath/available/readonly/'
{quote}
if we added a 'readonly' znode under 'available' znode, we need to exclude it
from available list. I would suggest not to add it under 'available' znode. I
had no strong feel where to put the znode. either is OK for me.
> Provide bookie readonly mode, when journal/ledgers flushing has failed with
> IOE
> -------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-199
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-199
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-server
> Affects Versions: 4.0.0
> Reporter: Rakesh R
> Assignee: Rakesh R
> Priority: Critical
> Fix For: 4.2.0
>
> Attachments: BOOKKEEPER-199.patch
>
>
> Bookkeeper should change to readonly(r-o) mode when the journal/ledgers
> flushing has failed with IOException. Later on, reject write requests on
> server side and will accept only the read requests from the clients, because
> even if flushing fails, the data in the bookie which has been flushed is
> still valid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
