[ 
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)

Reply via email to