[DIRMINA-902] Buffer read incorrectly when reading after a NEED_DATA trigger.

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Not A Problem
• Affects Version/s: 2.0.4
• Fix Version/s: 2.0.8
• Component/s: Core
• Labels: NEED_DATA buffer core position
• Environment: Ubuntu 12.04, 64-bit, OpenJDK 7
• Assignee: Unassigned
• Reporter: Nagesh
• Created: 31/Jul/12 09:34
• Updated: 11/Sep/14 21:33
• Resolved: 11/Sep/14 21:33

Description

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 !