[
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
