[
http://issues.apache.org/jira/browse/DIRMINA-45?page=comments#action_66057 ]
Alex commented on DIRMINA-45:
-----------------------------
Exactly. My decode always returns OK. I don't know why but it was called twice
and then there is nothing to read but still I return OK.
Let's do it in another way. You tell me what is wrong in my decode.
I send the simplified version of my decode method.
public MessageDecoderResult decode(ProtocolSession session, ByteBuffer in,
ProtocolDecoderOutput out)
throws ProtocolViolationException {
long l = in.getLong();
//out.write(msg);
return MessageDecoder.OK;
}
And let's assume that buffer has only one long.
Is there anything wrong in this decode?
> DemuxingProtocolCodecFactory.doDecode is called even after the buffer is
> empty.
> -------------------------------------------------------------------------------
>
> 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
> Fix For: 0.7.2
>
> 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
