[
https://issues.apache.org/jira/browse/BOOKKEEPER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087008#comment-13087008
]
Flavio Junqueira commented on BOOKKEEPER-50:
--------------------------------------------
I guess I don't understand your scenario then. From the original description, I
understand that a read request hits a bookie that has never seen the ledger of
the request before, consequently the result of the read is null. Your second
comment says that this particular case happens during recovery.
In my interpretation, it doesn't matter if this is for recovery or not. If a
read hits a bookie and the bookie hasn't heard of the ledger, then it shouldn't
create auxiliary data structures. In the case of recovery, we will need to
bootstrap the ledger in the case the client has something to write.
Let me give a more concrete example to illustrate. Suppose that we have 3
bookies and we write each entry to two bookies. The writer client writes the
first entry to one bookie and crashes. The first client that tries to read from
that ledger will have to recover it. While recovering, it will request entries
from two bookies that have never seen the ledger. In my understanding such
bookies should not create a ledger descriptor upon an attempt to read from the
ledger. One of these bookies will have to create a ledger descriptor when the
client tries to replicate the single entry.
Does it make sense to you?
> NullPointException at LedgerDescriptor#cmpMasterKey
> ---------------------------------------------------
>
> Key: BOOKKEEPER-50
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-50
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-server
> Affects Versions: 3.4.0
> Reporter: xulei
> Attachments: bookkeeper-50.patch
>
>
> the LedgerDescriptor will be created when it is missed in LedgerCache.
> NullPointException will be thrown out in the following case:
> 1. The ledger descriptor is created and cached to LedgerCache because of a
> readEntry operation in bookie. The ledger descriptor was created without
> setting master key (we don't know master key in a read request)
> 2. An addEntry is sent after 1 . since the ledger descriptor has been cached,
> so addEntry will use it to compare master key. then NullPointException is
> thrown out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
