+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<gal...@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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev