[jboss-jira] [JBoss JIRA] Commented: (JGRP-1339) STREAMING_STATE_TRANSFER: use_default_transport might lead to incorrect state transfer

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611978#comment-12611978 ] 

Bela Ban commented on JGRP-1339:
--------------------------------

If we do close the barrier, https://issues.jboss.org/browse/JGRP-1341 will ensure that the state chunks are still received, as they are unicast messages

> 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