[jgroups-dev] org.jgroups.Message and offset

Just as an FYI, I wanted to make you aware of a potential bug using 
org.jgroups.Message's getRawBuffer().

Every Message has a byte[] buffer which carries the payload, and an 
offset and length. Consider a large buffer of 512 bytes was passed to 
the Message constructor, and the offset is 300 and the length 212.

Message.getBuffer() will create a *copy* of the bytes in range [300-512] 
and return the copy. Note that if offset was 0 and buffer.length was 
212, then the actual buffer would be returned, and no copy would be made.

However, Message.getRawBuffer() always returns the *reference to buffer* 
and never makes a copy. This means that an application calling it needs 
to take offset and length into account. Consider a case where we want to 
use the payload of a Message to deserialize application data:

WRONG:
MyObject obj=deserialize(msg.getRawBuffer()); // starts reading at offset 0


RIGHT:
MyObject obj=deserialize(msg.getRawBuffer(), *msg.getOffset, 
msg.getLength()*);
MyObject obj=deserialize(msg.getBuffer()); // makes a copy

The first call is preferred as it doesn't need a copy; this could be 
used for instance if deserialize() didn't accept offset and length 
parameters. The second call can be used if deserialize only accepts a 
byte[] buffer parameter.

The reason this bug hasn't reared its ugly head so far is that JGroups 
always made a defensive copy of the byte[] buffer, so offset was always 
0 and buf.length was always length.

This defensive copy was eliminated in [1] (JGroups 3.5), so now offset 
can actually be > 0. Hibernate Search has run into this [2], so make 
sure to check your uses of Message.getRawBuffer() !
Cheers,

[1] https://issues.jboss.org/browse/JGRP-1773
[2] https://hibernate.atlassian.net/browse/HSEARCH-1532

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Javagroups-development mailing list