[ 
http://issues.apache.org/jira/browse/DIRMINA-45?page=comments#action_65920 ]
     
Alex commented on DIRMINA-45:
-----------------------------

In my case buffer has only one message.
When decode is called I decode that message (whole buffer) and return OK.
Then doDecode will call decode again, althought it is not necessary since whole 
buffer was already processed! So, I don't like that my decode is unnecessarly 
called twice. Do you mean that I should implement decode in such way that it 
will check if buffer is fully processed and return NEED_DATA? or if buffer has 
incomplete message or even EMPTY message I should return NEED_DATA?

Alex

> DemuxingProtocolCodecFactory.doDecode returns wrong value
> ---------------------------------------------------------
>
>          Key: DIRMINA-45
>          URL: http://issues.apache.org/jira/browse/DIRMINA-45
>      Project: Directory MINA
>         Type: Bug
>     Versions: 0.7.1
>  Environment: JDK1.4.2
>     Reporter: Alex
>     Assignee: Trustin Lee

>
> I am not sure if it is a bug or I just misunderstood something.
> I am implementing a protocol and use Demuxing* classes.
> When I return MessageDecoder.OK from my MessageDecoder's decode method, MINA 
> tries repeatedly calls this method again. If I return 
> MessageDecoder.NEED_DATA everything goes fine.
> So, I would expect completely reversal behaviour.
> I checked CumulativeProtocolDecoder and DemuxingProtocolCodecFactory classes.
> In CumulativeProtocolDecoder.decode it says that doDecode is invoked 
> repeatedly until it returns false. Fine. But what "false" means here? I would 
> guess that it means that buffer was completely decoded and no more data is 
> needed. But DemuxingProtocolCodedFactory.doDecode returns true if decoder 
> returned MessageDecoder.OK and false if decoder returned 
> MessageDecoder.NEED_DATA. Isn't wrong here?
> Alex

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to