directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex (JIRA)" <>
Subject [jira] Commented: (DIRMINA-45) DemuxingProtocolCodecFactory.doDecode returns wrong value
Date Sat, 21 May 2005 12:00:52 GMT
     [ ]
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


> DemuxingProtocolCodecFactory.doDecode returns wrong value
> ---------------------------------------------------------
>          Key: DIRMINA-45
>          URL:
>      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:
For more information on JIRA, see:

View raw message