+1.
There is also something else I wanted to bring to your attention. When
you pass reference byte[] BUF to JGroups, JGroups will store BUF in the
org.jgroups.Message MSG.
MSG is subsequently stored in the retransmission table of NAKACK.
If you now modify the contents of BUF, you will modify a subsequent
potential retransmission of MSG as well !
I don't think this is done currently (Infinispan uses a new buffer every
time), but just make sure buffer reuse doesn't get rolled into a new
design...
On 6/14/11 12:54 PM, Sanne Grinovero wrote:
2011/6/14 Galder Zamarreño<galder(a)redhat.com>:
> I like the idea but as Manik hinted I wonder how many people are gonna go and
configure this unless Infinispan is blatant enough for the users to tell them their
configuration is not optimal.
>
> We also need to consider the importance of the problem which is that STABLE keeps the
whole buffer ref around.
>
> Before doing anything further, we should repeat the tests and see what GC looks like
on sender side with the current adaptive buffer sizing.
My understanding is that at the point the buffer reaches JGroups, and
so gets into the STABLE "long lifecycle" we already know the exact
size so we can do a last resize.
The issue still looks to me about minimizing the amount of resizes
needed until we reach that point.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss