Uploaded image for project: 'MINA'
  1. MINA
  2. DIRMINA-902

Buffer read incorrectly when reading after a NEED_DATA trigger.

    Details

    • 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
    • Environment:
      Ubuntu 12.04, 64-bit, OpenJDK 7

      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 !

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        Most certainly a bug in the user's implementation. Difficult to tell, the provided informations are less that enough .

        Show
        elecharny Emmanuel Lecharny added a comment - Most certainly a bug in the user's implementation. Difficult to tell, the provided informations are less that enough .

          People

          • Assignee:
            Unassigned
            Reporter:
            codeboy Nagesh
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development