[jbosscache-dev] Re: Any reason not to use ExposedByteArrayOutputStream instead of ByteArrayOutputStream ?
cc'ing JBC-dev.
The stream looks good, except that getting the raw buffer would mean
that the buffer returned would "almost certainly be longer than the
data written to it" (quoted from Brian's excellent javadocs). Bela,
how would JGroups behave with this? Would it attempt to stream the
entire buffer, including uninitialized values?
Will need to see how this gets de-serialized as well. Also, since all
cacheloaders use the same marshaller, will need to see how they deal
with this as well. Any code that relies on buf.length may end up at
best writing unnecessary data and at worst breaking when deserializing.
Cheers
Manik
On 3 Jul 2008, at 20:37, Bela Ban wrote:
Good ! I see that our friend Brian added code to EBAOS to double the
byte array and - after a certain limit - grow only linearly. Good
thing, this should help keep memory consumption down even more
Manik Surtani wrote:
> Yes, good point - will investigate.
>
> On 3 Jul 2008, at 16:59, Bela Ban wrote:
>
>> At least in AbstractMarshaller:
>> public byte[] objectToByteBuffer(Object obj) throws Exception
>> {
>> ByteArrayOutputStream baos = new ByteArrayOutputStream();
>> ObjectOutputStream out =
>> ObjectSerializationFactory.createObjectOutputStream(baos);
>> objectToObjectStream(obj, out);
>> out.close();
>> return baos.toByteArray();
>> }
>>
>> Here, an ExposedByteArrayOutputStream instead of a BAOS would
>> prevent the COPY of the byte buffer. We also don't need to be
>> concerned about reentrancy as the output streams are local (stack)
>> variables...
>>
>> Maybe you guys should take a look at all occurrences of BAOS !
>>
>> --
>> Bela Ban
>> Lead JGroups / JBoss Clustering team
>> JBoss - a division of Red Hat
>>
>
> --
> Manik Surtani
> Lead, JBoss Cache
> manik(a)jboss.org
>
>
>
>
>
>
--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org