Overall +1 for 4.14.0 - the milestone is due May 16th anyway.
There is nothing that breaks compatibility with 4.13 so we can skip 4.13.1.
One thing I'd love to see in 4.14 is
https://github.com/apache/bookkeeper/pull/2696 , to fix
https://github.com/netty/netty/issues/10986
It looks like there are
+1 We should do 4.14, carrying all the fixes that are there in master as well.
--
Matteo Merli
On Tue, May 4, 2021 at 11:57 AM Sijie Guo wrote:
>
> +1
>
> On Tue, May 4, 2021 at 2:22 AM Yunze Xu
> wrote:
>
> > Hello,
> > About 10 days ago I found a heap memory copy problem in Apache Pulsar, s
+1
On Tue, May 4, 2021 at 2:22 AM Yunze Xu
wrote:
> Hello,
> About 10 days ago I found a heap memory copy problem in Apache Pulsar, see
> [1].
> It’s a problem of BK side because when `LedgerHandle#asyncAddEntry`
> accepts a `CompositeByteBuf` or a wrapper, it will finally call
> `ByteBuf#nioBuf
> how you justify removing the ledger as opposed to removing the ledger
storage and preserving the journal
I will be waiting for the BP on this point too. :) But glad to see that we
are working to avoid double writes. :)
With the EntryLogPerLedger (ELPL) feature, it is a more-or-less journal per
l
Il giorno mar 4 mag 2021 alle ore 11:22 Yunze Xu
ha scritto:
>
> Hello,
> About 10 days ago I found a heap memory copy problem in Apache Pulsar, see
> [1].
> It’s a problem of BK side because when `LedgerHandle#asyncAddEntry` accepts a
> `CompositeByteBuf` or a wrapper, it will finally call `Byt
Hello,
About 10 days ago I found a heap memory copy problem in Apache Pulsar, see [1].
It’s a problem of BK side because when `LedgerHandle#asyncAddEntry` accepts a
`CompositeByteBuf` or a wrapper, it will finally call `ByteBuf#nioBuffer()`,
which would make a heap copy from direct memory.
[2] fi
