Perhaps we need a place to set the allocator.. Pooled versus Unpooled..
PooledRepository.getPool()... Regarding the ref counts.. we will need to add a new reference counting.. the current one is a bit complex to be used because of delivering.. DLQs.. etc... it's a big challenge for sure! On Fri, May 26, 2017 at 4:04 AM, Martyn Taylor <[email protected]> wrote: > We've had using buffer pools throughout on the backlog for a long time, so > +1 on this. The only thing I'd say here is that retrofitting the reference > counting (i.e. releasing the buffers) can sometimes lead to leaks, if we > don't catch all cases, so we just need to be careful here. > > One other thing to consider, we do have users that run Artemis in > constrained environments, where memory is limited. Allocating a chunk of > memory upfront for the buffers may not be ideal for that use case. > > Cheers > > On Thu, May 25, 2017 at 5:53 PM, Matt Pavlovich <[email protected]> wrote: > >> +1 this all sounds great >> >> > On May 12, 2017, at 12:02 PM, Michael André Pearce < >> [email protected]> wrote: >> > >> > I agree iterative targeted steps is best. >> > >> > So if even just pooling messages and keep the copying of the buffer as >> today it's a step in the right direction. >> > >> > >> > Sent from my iPhone >> > >> >> On 12 May 2017, at 15:52, Clebert Suconic <[email protected]> >> wrote: >> >> >> >> I'm not sure we can keep the message body as a native buffer... >> >> >> >> I have seen it being expensive. Especially when dealing with >> >> clustering and paging.. a lot of times I have seen memory exaustion... >> >> >> >> for AMQP, on qpid Proton though.. that would require a lot more >> >> changes.. it's not even possible to think about it now unless we make >> >> substantial changes to Proton.. Proton likes to keep its own internal >> >> pool and make a lot of copies.. so we cannot do this yet on AMQP. (I >> >> would like to though). >> >> >> >> >> >> >> >> >> >> But I'm always in advocating of tackling one thing at the time... >> >> first thing is to have some reference counting in place to tell us >> >> when to deallocate the memory used by the message, in such way it >> >> works with both paging and non paging... anything else then will be >> >> "relatively' easier. >> >> >> >> >> >> >> >> On Fri, May 12, 2017 at 2:56 AM, Michael André Pearce >> >> <[email protected]> wrote: >> >>> >> >>> Hi Clebert. >> >>> >> >>> +1 from me definitely. >> >>> >> >>> Agreed this def should target the server not the clients. >> >>> >> >>> Having the message / buffer used my message pooled would be great, as >> will reduce GC pressure. >> >>> >> >>> I would like to take that one step further and question if we could >> actually avoid copying the buffer contents at all on passing from/to netty. >> The zero-copy nivana. >> >>> >> >>> I know you state to have separate buffer pools. But if we could use >> the same memory address we can avoid the copy, reducing latency also. This >> could be done by sharing the buffer and the pool, or by using >> slice/duplicate retained. >> >>> >> >>> Cheers >> >>> Mike >> >>> >> >>> >> >>> >> >>>> On 11 May 2017, at 23:13, Clebert Suconic <[email protected]> >> wrote: >> >>>> >> >>>> One thing I couldn't do before without some proper thinking was to use >> >>>> a Pooled Buffer on the message bodies. >> >>>> >> >>>> It would actually rock out the perf numbers if that could be >> achieved... >> >>>> >> >>>> >> >>>> I'm thinking this should be done on the server only. Doing it on the >> >>>> client would mean to give some API to users to tell when the message >> >>>> is gone and no longer needed.. I don't think we can do this with JMS >> >>>> core, or any of the qpid clients... although we could think about an >> >>>> API in the future for such thing. >> >>>> >> >>>> >> >>>> >> >>>> For the server: I would need to capture when the message is released.. >> >>>> the only pitfal for this would be paging as the Page read may come and >> >>>> go... So, this will involve some work on making sure we would call the >> >>>> proper places. >> >>>> >> >>>> >> >>>> We would still need to copy from Netty Buffer into another >> >>>> PooledBuffer as the Netty buffer would need to be a Native buffer >> >>>> while the message a regular Buffer (non Native). >> >>>> >> >>>> >> >>>> I am thinking of investing my time on this (even if my spare time if >> >>>> needed be) after apache con next week. >> >>>> >> >>>> >> >>>> This will certainly attract Francesco and Michael Pierce's attention.. >> >>>> but this would be a pretty good improvement towards even less GC >> >>>> pressure. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Clebert Suconic >> >> >> >> >> >> >> >> -- >> >> Clebert Suconic >> >> -- Clebert Suconic
