You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2014/09/05 12:48:33 UTC
[jira] [Updated] (DIRMINA-902) Buffer read incorrectly when reading
after a NEED_DATA trigger.
[ https://issues.apache.org/jira/browse/DIRMINA-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-902:
--------------------------------------
Fix Version/s: (was: 2.0.4)
2.0.8
> Buffer read incorrectly when reading after a NEED_DATA trigger.
> ---------------------------------------------------------------
>
> Key: DIRMINA-902
> URL: https://issues.apache.org/jira/browse/DIRMINA-902
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.4
> Environment: Ubuntu 12.04, 64-bit, OpenJDK 7
> Reporter: Nagesh
> Labels: NEED_DATA, buffer, core, position
> Fix For: 2.0.8
>
>
> The decoder returns NEED_DATA when it detects that more data is required. When the control comes back to this decoder, the first byte is no longer the same as the one that was read originally. I feel that, the first byte read second time, is the first byte of the buffer made available second time; not the first byte of concatenation of the first and the second chunk.
> The following are chunks as reported by the logger:
> 131764 [NioProcessor-4] INFO org.apache.mina.filter.logging.LoggingFilter - RECEIVED: HeapBuffer[pos=0 lim=512 cap=512: ...]
> 139692 [NioProcessor-4] INFO org.apache.mina.filter.logging.LoggingFilter - RECEIVED: HeapBuffer[pos=0 lim=1024 cap=1024: ...]
> 143453 [NioProcessor-4] INFO org.apache.mina.filter.logging.LoggingFilter - RECEIVED: HeapBuffer[pos=0 lim=2048 cap=2048: ...]
> 146121 [NioProcessor-4] INFO org.apache.mina.filter.logging.LoggingFilter - RECEIVED: HeapBuffer[pos=0 lim=657 cap=4096: ...]
> The following is the value of the first byte (in decimal) as read by IoBuffer.get():
> 48
> 84
> 101
> 105
> Of the above, only the first one (48) is correct.
> Also, when traced in Wireshark, only two chunks are shown - one of 17 bytes and the other of 4224.
> I am unable to implement my protocol due to this behavior. Help !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)