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
