Nagesh created DIRMINA-902:
------------------------------
Summary: 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
Fix For: 2.0.4
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
