activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Use pooled buffers on message body
Date Fri, 26 May 2017 14:50:16 GMT
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 <mtaylor@redhat.com> 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 <mattrpav@gmail.com> wrote:
>
>> +1 this all sounds great
>>
>> > On May 12, 2017, at 12:02 PM, Michael André Pearce <
>> michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com>
>> 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
>> >> <michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com>
>> 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

Mime
View raw message