Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
From: Matt Pavlovich <mattrpav@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [DISCUSS] Use pooled buffers on message body
Date: Fri, 26 May 2017 10:22:57 -0500
References: <CAKF+bsoS2EK2mgTHRtYkkRVoZCDOxj_Rg3v=HWwcvRAo_7+m4g@mail.gmail.com>
 <2CAEBF51-1F38-432B-AEF8-8B88C11A05F2@me.com>
 <CAKF+bso4kBm77pq=9fM7p0QyCNv7-H029UodokiM5Kzc7aYGog@mail.gmail.com>
 <07A679E3-34B7-4864-B9EA-763FC6E26E0A@me.com>
 <92D4B321-146D-4C22-891F-7092B285E5D6@gmail.com>
 <CAH6wpnoYg5bRD6smf=u0gFeKBaNoFc1TANousnUOXvDT=QP+2A@mail.gmail.com>
 <CAKF+bsqw8oZbOGoLX50Br=SNzTb7Ru+Vu0Avwp9C+JAO5Nbc6A@mail.gmail.com>
To: dev@activemq.apache.org
In-Reply-To: <CAKF+bsqw8oZbOGoLX50Br=SNzTb7Ru+Vu0Avwp9C+JAO5Nbc6A@mail.gmail.com>
Message-Id: <EE4AE789-7072-4F12-87EE-142100AA5AFC@gmail.com>
archived-at: Fri, 26 May 2017 15:23:04 -0000

+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 =
<clebert.suconic@gmail.com> wrote:
>=20
> Perhaps we need a place to set the allocator.. Pooled versus =
Unpooled..
>=20
>=20
> PooledRepository.getPool()...
>=20
>=20
>=20
> 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!
>=20
> 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.
>>=20
>> 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.
>>=20
>> Cheers
>>=20
>> On Thu, May 25, 2017 at 5:53 PM, Matt Pavlovich <mattrpav@gmail.com> =
wrote:
>>=20
>>> +1 this all sounds great
>>>=20
>>>> On May 12, 2017, at 12:02 PM, Michael Andr=C3=A9 Pearce <
>>> michael.andre.pearce@me.com> wrote:
>>>>=20
>>>> I agree iterative targeted steps is best.
>>>>=20
>>>> So if even just pooling messages and keep the copying of the buffer =
as
>>> today it's a step in the right direction.
>>>>=20
>>>>=20
>>>> Sent from my iPhone
>>>>=20
>>>>> On 12 May 2017, at 15:52, Clebert Suconic =
<clebert.suconic@gmail.com>
>>> wrote:
>>>>>=20
>>>>> I'm not sure we can keep the message body as a native buffer...
>>>>>=20
>>>>> I have seen it being expensive. Especially when dealing with
>>>>> clustering and paging.. a lot of times I have seen memory =
exaustion...
>>>>>=20
>>>>> 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).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Fri, May 12, 2017 at 2:56 AM, Michael Andr=C3=A9 Pearce
>>>>> <michael.andre.pearce@me.com> wrote:
>>>>>>=20
>>>>>> Hi Clebert.
>>>>>>=20
>>>>>> +1 from me definitely.
>>>>>>=20
>>>>>> Agreed this def should target the server not the clients.
>>>>>>=20
>>>>>> Having the message / buffer used my message pooled would be =
great, as
>>> will reduce GC pressure.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Cheers
>>>>>> Mike
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 11 May 2017, at 23:13, Clebert Suconic =
<clebert.suconic@gmail.com>
>>> wrote:
>>>>>>>=20
>>>>>>> One thing I couldn't do before without some proper thinking was =
to use
>>>>>>> a Pooled Buffer on the message bodies.
>>>>>>>=20
>>>>>>> It would actually rock out the perf numbers if that could be
>>> achieved...
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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).
>>>>>>>=20
>>>>>>>=20
>>>>>>> I am thinking of investing my time on this (even if my spare =
time if
>>>>>>> needed be) after apache con next week.
>>>>>>>=20
>>>>>>>=20
>>>>>>> This will certainly attract Francesco and Michael Pierce's =
attention..
>>>>>>> but this would be a pretty good improvement towards even less GC
>>>>>>> pressure.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> Clebert Suconic
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> Clebert Suconic
>>>=20
>>>=20
>=20
>=20
>=20
> --=20
> Clebert Suconic