[jira] [Commented] (BOOKKEEPER-572) Make the journal a write ahead log

2013-04-17 Thread Ivan Kelly (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634019#comment-13634019
 ] 

Ivan Kelly commented on BOOKKEEPER-572:
---

{quote}
the problem is you only get the exception after added the entry to journal. so 
the entry lives in journal. when bookie started, replaying this journal tried 
to add the entry to ledger storage, but it would failed. so the bookie could 
not start.
{quote}
And this can be handled at that point. We should separate what we consider 
writing errors (errors with the write medium) and data errors (errors with the 
entry). Data errors can be logged as a warn. Whats more, we can simply 
prevalidate the entries. The contents of an entry should really be opaque to 
the ledger storage, it's an unfortunate historical fact that they are not. The 
ledger storage tries to read the ledger id  the entry id and stores based on 
this. We can prevalidate to ensure that everything we pass to ledger storage 
has at least 16 bytes of length.

{quote}the COW is just for ledger index. it works for both skiplists and 
interleaved.{quote}
This is true. It would mean either having a separate set of pages for read and 
write, or that we have a lookaside cache for index entries. Have you done any 
implementation on this? I think it would be a good thing to have whether this 
goes in or not. If so, have you measured how much memory it uses?

 Make the journal a write ahead log
 --

 Key: BOOKKEEPER-572
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-572
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Ivan Kelly
Assignee: Ivan Kelly
 Fix For: 4.3.0

 Attachments: 
 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch, 
 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch, 
 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch, 
 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch, 
 0003-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch, 
 0003-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch, 
 BookieServer-2013-02-22.snapshot


 A bookie adds to the LedgerStorage before writing to the journal. This is the 
 fundamental problem behind BOOKKEEPER-447 and blocks a nice solution to 
 BOOKKEEPER-530. By writing to the memory state before the journal, we exposed 
 ourselves to bugs if the bookie crashed before we wrote to the journal. The 
 entry may exist in index, but not in the entrylog, a situation which cannot 
 be distinguished from an I/O error. The comments on BOOKKEEPER-447 goes into 
 more details. 

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


[jira] [Commented] (BOOKKEEPER-564) Better checkpoint mechanism

2013-04-17 Thread Ivan Kelly (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634026#comment-13634026
 ] 

Ivan Kelly commented on BOOKKEEPER-564:
---

{quote}
How it worked in previous flow on testing LedgerStorage in isolation? I don't 
quite understand about this part.
{quote}
We don't. We always construct a full bookie, because it's impossible to test 
the ledger storage without the bookie.
{code}
grep -r new InterleavedLedgerStorage bookkeeper-server/src/test/java
{code}
Another place I came across this was with the bkvhbase benchmark. I had to 
implement my own SyncThread.

{quote}
in previous flow, sync thread just checkpoint blindly. in current flow, ledger 
storage would tell the syncthread (the checkpointer) the point which is a 
better point to do checkpoint. the only thing that ledger storage gave out is 
the point to guide checkpoint. but if you mean the guide is coupling, I have 
nothing more to say.{quote}
It's a command rather than a guide. And how the ledger storage behaves is 
dependent on the sync thread. This is coupling.

 Better checkpoint mechanism
 ---

 Key: BOOKKEEPER-564
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-564
 Project: Bookkeeper
  Issue Type: Improvement
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Sijie Guo
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-564-Better-checkpoint-mechanism.patch, 
 0001-BOOKKEEPER-564-Better-checkpoint-mechanism.patch, 
 0002-BOOKKEEPER-564-Better-checkpoint-mechanism.patch, BOOKKEEPER-564.patch, 
 BOOKKEEPER-564.patch


 Currently, SyncThread made a checkpoint too frequently, which affects 
 performance. data is writing to entry logger file might be blocked by syncing 
 same entry logger file, which affect bookie to achieve higher throughput. We 
 could schedule checkpoint only when rotating an entry log file. so new 
 incoming entries would be written to newer entry log file and old entry log 
 file could be synced.

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