+1 - Michael
On Wed, Dec 22, 2021 at 6:10 AM Hang Chen <chenh...@apache.org> wrote: > > +1 > > Thanks, > Hang > > PengHui Li <peng...@apache.org> 于2021年12月22日周三 19:28写道： > > > > +1 > > > > Penghui > > > > On Wed, Dec 22, 2021 at 6:57 PM ZhangJian He <shoot...@gmail.com> wrote: > > > > > +1 > > > > > > Christophe Bornet <bornet.ch...@gmail.com> 于2021年12月22日周三 17:38写道： > > > > > > > +1 > > > > > > > > Le mer. 22 déc. 2021 à 00:46, Matteo Merli <mme...@apache.org> a écrit : > > > > > > > > > This is the voting thread for PIP-120. It will stay open for at least > > > > 48h. > > > > > > > > > > https://github.com/apache/pulsar/issues/13306 > > > > > > > > > > -------- > > > > > > > > > > ## Motivation > > > > > > > > > > In Pulsar 2.8, we have introduced a setting to control the amount of > > > > memory > > > > > used by a client instance. > > > > > > > > > > ```java > > > > > interface ClientBuilder { > > > > > ClientBuilder memoryLimit(long memoryLimit, SizeUnit unit); > > > > > } > > > > > ``` > > > > > > > > > > By default, in 2.8 and 2.9 this setting is set to 0, meaning no limit > > > is > > > > > being > > > > > enforced. > > > > > > > > > > I think it's a good time for 2.10 to enable this setting by default > > > and, > > > > > correspondingly, to disable by default the producer queue size limit. > > > > > > > > > > This will simplify a lot the configuration that a producer application > > > > will > > > > > have to come up with, when publishing with many topic/partitions or > > > > > when messages > > > > > are bigger than expected. > > > > > > > > > > ## Proposed changes > > > > > > > > > > In 2.10 release, for the `ClientBuilder`, change > > > > > * `memoryLimit`: 0 -> 64 MB > > > > > > > > > > For the `ProducerBuilder`, changes > > > > > * `maxPendingMessages`: 1000 -> 0 > > > > > > > > > > 64MB is picked because it's a small enough memory size that will > > > > guarantee > > > > > a very high producer throughput, irrespective of the individual > > > messages > > > > > size. > > > > > > > > > > > > > > > -- > > > > > Matteo Merli > > > > > <mme...@apache.org> > > > > > > > > > > > >
