[
https://issues.apache.org/jira/browse/QPIDJMS-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597798#comment-17597798
]
ASF subversion and git services commented on QPIDJMS-572:
---------------------------------------------------------
Commit 68ecb7a3e36f2d17b7b17fed33ba607591ed4209 in qpid-jms's branch
refs/heads/1.x from Timothy Bish
[ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=68ecb7a3 ]
QPIDJMS-572 Ensure that readable buffer string read consumes the bytes
Ensures that when reading a string the readable buffer consumes the
bytes by advancing the read index as defined in the interface API docs.
(cherry picked from commit f7564d558dfc364284b1bd099242d044d422514c)
> The internal Netty ReadableBuffer wrapper read string API not advancing
> position index
> --------------------------------------------------------------------------------------
>
> Key: QPIDJMS-572
> URL: https://issues.apache.org/jira/browse/QPIDJMS-572
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 2.0.0
> Reporter: Timothy A. Bish
> Assignee: Timothy A. Bish
> Priority: Minor
> Fix For: 2.1.0
>
>
> The ReadableBuffer API from proton-j provides methods for reading a string
> from the remaining readable bytes in the buffer and documents these methods
> should advance the read index to the limit on return. The Qpid JMS readable
> buffer isn't advancing the position as it passes the decoding off to a Netty
> toString call which does not advance the read index. This is masked in
> proton-j currently as all string decodes are done from slices of a buffer or
> in some cases a duplicate and the buffer slice is cast off afterwards without
> care for any remaining bytes. Should proton-j be updated to not rely on
> slices for every single string decode this breaks the codec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
