You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Sijie Guo (JIRA)" <ji...@apache.org> on 2012/10/18 16:36:03 UTC

[jira] [Comment Edited] (BOOKKEEPER-346) Detect IOExceptions in LedgerCache and bookie should look at next ledger dir(if any)

    [ https://issues.apache.org/jira/browse/BOOKKEEPER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479034#comment-13479034 ] 

Sijie Guo edited comment on BOOKKEEPER-346 at 10/18/12 2:34 PM:
----------------------------------------------------------------

sorry for late response. the overall of the patch looks good to me. I had some comments listed as below:

1) about Journal entries. 

for journal entry, I would suggest to move logging journal entries to Journal. so we had a centralized place to manage all journal entry format. so we had 3 kind of entries now.

a) AddEntry: for added entry. call logAddEntry to record a journal entry in journal.
b) MasterKeyEntry: log master key for a ledger. call logMasterKey(long ledgerId, byte[] masterKey) and in #logMasterKey, it build the ByteBuffer and write to journal.
c) LedgerStorageChanges: log changes of a ledger storage. call logLedgerStorageChanges(long ledgerId, ByteBuffer changes) and in #logLedgerStorageChanges you build the ByteBuffer and write to journal.

when replaying journal, Journal dispatched to different methods when encountering different type of journal entries. the skeleton code of Journal would be something like below (the wordings might be not correct. please feel free to correct them):

{code}
class Journal {

void logAddEntry(ByteBuffer entry, ...) // log an addEntry operation

void logMasterKey(long ledgerId, byte[] masterKey) // log the master key of a ledger

void logLedgerStorageChanges(long ledgerId, ByteBuffer changes) // log changes from a ledger storage. 

}

class JournalScanner {

void onAddEntry(ByteBuffer) {
// handle add entry 
}

void onMasterKey(long ledgerId, byte[] masterKey) {
// handle master key
}

void onLedgerStorageChanged(long ledgerId, ByteBuffer changes) {
// handle ledger storage changes (like a ledger index relocation in InterLeavedLedgerStorage)
}

}
{code} 

so all the journal entry details and constants defines could be managed by Journal, we don't need to spread the journal format code all overal other files.

2) I am not sure is there any better solution to record the relocation? otherwise using current journal entry, you had to replay the journal twice. In most time, it wasted time. I don't have better idea now, needs to think more about it.

  
                
      was (Author: hustlmsp):
    sorry for late response. the overall of the patch looks good to me. I had some comments listed as below:

1) about Journal entries. 

for journal entry, I would suggest to move logging journal entries to Journal. so we had a centralized place to manage all journal entry format. so we had 3 kind of entries now.

a) AddEntry: for added entry. call logAddEntry to record a journal entry in journal.
b) MasterKeyEntry: log master key for a ledger. call logMasterKey(long ledgerId, byte[] masterKey) and in #logMasterKey, it build the ByteBuffer and write to journal.
c) LedgerIndexRelocate: log a relocation of a ledger index file. call logLedgerIndexRelocation(long ledgerId, File oldFile, File newFile) and in #logLedgerIndexRelocation you build the ByteBuffer and write to journal.

when replaying journal, Journal dispatched to different methods when encountering different type of journal entries. the skeleton code of Journal would be something like below (the wordings might be not correct. please feel free to correct them):

{code}
class Journal {

void logAddEntry(ByteBuffer entry, ...) // log an addEntry operation

void logMasterKey(long ledgerId, byte[] masterKey) // log the master key of a ledger

void logLedgerStorageChanges(long ledgerId, ByteBuffer changes) // log changes from a ledger storage. 

}

class JournalScanner {

void onAddEntry(ByteBuffer) {
// handle add entry 
}

void onMasterKey(long ledgerId, byte[] masterKey) {
// handle master key
}

void onLedgerStorageChanged(long ledgerId, ByteBuffer changes) {
// handle ledger storage changes (like a ledger index relocation in InterLeavedLedgerStorage)
}

}
{code} 

so all the journal entry details and constants defines could be managed by Journal, we don't need to spread the journal format code all overal other files.

2) I am not sure is there any better solution to record the relocation? otherwise using current journal entry, you had to replay the journal twice. In most time, it wasted time. I don't have better idea now, needs to think more about it.

  
                  
> Detect IOExceptions in LedgerCache and bookie should look at next ledger dir(if any)
> ------------------------------------------------------------------------------------
>
>                 Key: BOOKKEEPER-346
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-346
>             Project: Bookkeeper
>          Issue Type: Sub-task
>          Components: bookkeeper-server
>    Affects Versions: 4.1.0
>            Reporter: Rakesh R
>            Assignee: Vinay
>             Fix For: 4.2.0
>
>         Attachments: BOOKKEEPER-346.patch, BOOKKEEPER-346.patch, BOOKKEEPER-346.patch, BOOKKEEPER-346.patch, BOOKKEEPER-346.patch, BOOKKEEPER-346.patch
>
>
> This jira to detect IOExceptions in "LedgerCache" to iterate over all the configured ledger(s).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira