On 5/23/11 6:44 PM, Sanne Grinovero wrote: > To keep stuff simple, I'd add an alternative feature instead: > have the custom externalizers to optionally recommend an allocation buffer > size. > > In my experience people use a set of well known types for the key, and > maybe for the value as well, for which they actually know the output > byte size, so there's no point in Infinispan to try guessing the size > and then adapting on it; an exception being the often used Strings, > even in composite keys, but again as user of the API I have a pretty > good idea of the size I'm going to need, for each object I store. > > Also in MarshalledValue I see that an ExposedByteArrayOutputStream is > created, and after serialization if the buffer is found to be bigger > than the buffer we're referencing a copy is made to create an exact > matching byte[]. > What about revamping the interface there, to expose the > ExposedByteArrayOutputStream instead of byte[], up to the JGroups > level?
No need to expose the ExposedByteArrayOutputStream, a byte[] buffer, offset and length will do it, and we already use this today. > In case the value is not stored in binary form, the expected life of > the stream is very short anyway, after being pushed directly to > network buffers we don't need it anymore... couldn't we pass the > non-truncated stream directly to JGroups without this final size > adjustement ? You do that, yes. However, afair, the issue is not on the *sending*, but on the *receiving* side. That's where the larger-than-needed buffer sticks around. On the sending side, as you mentioned, Infinispan passes a buffer/offset/length to JGroups and JGroups passes this right on to the network layer, which copies that data into a buffer. -- Bela Ban Lead JGroups / Clustering Team JBoss _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev