]
Bela Ban commented on JGRP-1339:
--------------------------------
Added a BlockingInputStream, which is used in STREAMING_STATE_TRANSFER. The functionality
of STREAMING_STATE_TRANSFER has been seperated into STREAMING_STATE_TRANSFER and
STREAMING_STATE_TRANSFER_SOCKET, with a common base class of StreamingStateTransfer.
Will probably rename STREAMING_STATE_TRANSFER --> STATE and
STREAMING_STATE_TRANSFER_SOCKET to STATE_SOCK.
STREAMING_STATE_TRANSFER: use_default_transport might lead to
incorrect state transfer
--------------------------------------------------------------------------------------
Key: JGRP-1339
URL:
https://issues.jboss.org/browse/JGRP-1339
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.2, 3.0
If read(byte[] buf, int offset, int len) is invoked on a StateInputStream, we do the
following:
- stateQueue.take() is called to grab the next message (block if no message is
available)
- Then we return the byte[] buffer of the message. The number of bytes returned is
buffer.length, *not* len !
This has 3 issues:
#1 It violates the contract of read(): if we wanted to read len bytes at most, we cannot
get more bytes back. E.g. if we wanted to read 500 bytes, but get 1000 back, then
that's incorrect
#2 If we allocate a buffer of 500 bytes, but the next message has 1000 bytes, we will get
an array out of bounds exception
#3 Even if this was correct, if we wanted to read 500 bytes, but the next message has
1000 bytes, we'd only read 500 bytes and throw the remainder away !
--
This message is automatically generated by JIRA.
For more information on JIRA, see: