[
https://issues.apache.org/jira/browse/DIRMINA-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRMINA-902.
---------------------------------------
Resolution: Not a Problem
Most certainly a bug in the user's implementation. Difficult to tell, the
provided informations are less that enough .
> 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)