[
https://issues.jboss.org/browse/JGRP-1339?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1339:
--------------------------------
Oh, I see now why this actually works: first the barrier is closed, then we call
handleStateRsp(), then the barrier is openened again. However, the handleStateRsp() is run
on a separate thread if use_default_transport=true, so handleStateRsp() returns
*immediately* !
Otherwise it would have blocked because the barrier is closed. I guess that's the
reason handleStateRsp() is run on a separate thread !@#@%$#@#% :-)
We might as well run this without closing/opening the barrier, but we have to look at the
implications of setting the digest and then, over a period of time, setting the state, and
investigate whether this is correct.
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:
http://www.atlassian.com/software/jira