[
https://issues.apache.org/jira/browse/BOOKKEEPER-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667721#comment-15667721
]
Andrey Yegorov commented on BOOKKEEPER-961:
-------------------------------------------
[~merlimat] I understand the motivation for decision to assign the write
requests for the same ledger to the same thread.
I do not understand why you have decided to do the same for reads. There is no
mutex, reads do not have to be in order. It is possible to get the case when
majority of reads (i.e. async reads) coming to the same ledger. As I
understand with this change the reads de-facto serialized. Did you see read
latency improvements with this change? Did you measure it with SSD or HDD?
> Assing read/write request for same ledger to a single thread
> ------------------------------------------------------------
>
> Key: BOOKKEEPER-961
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-961
> Project: Bookkeeper
> Issue Type: Improvement
> Affects Versions: 4.4.0
> Reporter: Matteo Merli
> Assignee: Matteo Merli
> Fix For: 4.5.0
>
>
> When entries for the same ledger are processed by the bookie we should avoid
> the reordering of the request. Currently, if multiple read/write threads are
> configured, the requests will be passed to the executor and writes for same
> ledger will be spread across multiple threads.
> This poses 2 issues:
> # Mutex contention to access the LedgerDescriptor
> # If the client receives add-entry acks out of order it has anyway to wait
> for the acks of previous entries before acknowledging the whole sequence
> to the application. In practice, the reordering is increasing the
> latency
> experienced by the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
