+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
