[
https://issues.apache.org/jira/browse/BOOKKEEPER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644077#comment-13644077
]
Sijie Guo edited comment on BOOKKEEPER-564 at 4/28/13 6:10 PM:
---------------------------------------------------------------
{code}
This patch doesn't explicitly do this, because SyncThread is an innerclass of
Bookie, but implicitly it's the exact same thing. Try making SyncThread a
static inner class and see what happens. Whats more, you don't even need the
circular dependency in your patch. SyncThread#newCheckpoint calls
journal#requestCheckpoint. You could simply have Journal implement
Checkpointer. But by now, the name Checkpointer doesn't make sense anymore, as
you aren't able to trigger a checkpoint action through the interface, so maybe
rename it to CheckpointSource. And if Journal is implementing this, you may as
well add checkpointComlete(Checkpoint) to CheckpointSource. And remove
Checkpoint#checkpointComplete(). So the SyncThread can call
journal.checkpointComplete(checkpoint), and it's clearer where the operation is
occurring. Checkpoint#checkpointComplete() looks a lot like action at a
distance.
{code}
ok. provide the CheckPointSource, which provide the method, newCheckpoint.
Journal implmented this interface. SyncThread doesn't change. so ledger storage
could get checkpoint from checkpointsource. If you agreed on it, I made the
change.
If you still don't like it, I would suggest keeping current SyncThread
unchanged. I would break the entrylogger preallocation into a separated jira.
was (Author: hustlmsp):
{code}
This patch doesn't explicitly do this, because SyncThread is an innerclass of
Bookie, but implicitly it's the exact same thing. Try making SyncThread a
static inner class and see what happens. Whats more, you don't even need the
circular dependency in your patch. SyncThread#newCheckpoint calls
journal#requestCheckpoint. You could simply have Journal implement
Checkpointer. But by now, the name Checkpointer doesn't make sense anymore, as
you aren't able to trigger a checkpoint action through the interface, so maybe
rename it to CheckpointSource. And if Journal is implementing this, you may as
well add checkpointComlete(Checkpoint) to CheckpointSource. And remove
Checkpoint#checkpointComplete(). So the SyncThread can call
journal.checkpointComplete(checkpoint), and it's clearer where the operation is
occurring. Checkpoint#checkpointComplete() looks a lot like action at a
distance.
{code}
ok. provide the CheckPointSource, which provide two method, newCheckpoint.
Journal implmented this interface. SyncThread doesn't change. so ledger storage
could get checkpoint from checkpointsource. If you agreed on it, I made the
change.
If you still don't like it, I would suggest keeping current SyncThread
unchanged. I would break the entrylogger preallocation into a separated jira.
> 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, 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
