@Martyn: you recently added some configuration on InVM to make pooled or Not.. where is that? Where is the pool right now after your changes?
I can read the code. but it's easier to ask... :) Perhaps we should make a class with a PoolServer for such things? Like, I'm looking into perhaps add a ClientTransaction retry, and i would use the pool there as well. it would be best to have such class somewhere. On Fri, May 26, 2017 at 11:22 AM, Matt Pavlovich <[email protected]> wrote: > +1 having the memory pool/allocator be a configurable strategy or policy-type > deal would be bonus level 12. Esp. for embedded / kiosk / Raspberry Pi and > linux host container scenarios as Martyn mentioned. > >> On May 26, 2017, at 9:50 AM, Clebert Suconic <[email protected]> >> wrote: >> >> 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 > -- Clebert Suconic
