[ http://issues.apache.org/jira/browse/DIRMINA-248?page=comments#action_12431905 ] Randy Watler commented on DIRMINA-248: --------------------------------------
Trustin, Very nice. One thing: I am currently using MessageDecoder/DemuxingProtocolCodecFactory. Question is whether I should refactor to use ProtocolDecoder or have you guys push the new finishDecode() protocol into MessageDecoder. I can pass up the demux functionality for the near term, but eventually it might be handy to have that support in there anyway. Please let me know if you'd like to have me test with a ProtocolDecoder impl first. I suppose once we prove that, we can push the protocol more widely. Thanks again, Randy > ProtocolDecoder should get notified when a connection is closed. > ---------------------------------------------------------------- > > Key: DIRMINA-248 > URL: http://issues.apache.org/jira/browse/DIRMINA-248 > Project: Directory MINA > Issue Type: Improvement > Reporter: Trustin Lee > Assigned To: Trustin Lee > Fix For: 0.9.5 > > > Randy Watlet wrote: > ================== > I am attempting to use Mina to build a scalable Ajax web application > test harness, (a Mina client). So far, so good... :-). > One quick question: I have an operational HTTP message decoder in place, > but I am not sure how to support the parsing of a complete HTTP response > when the HTTP Content-length is not known. In particular, I need to know > when the underling session is closing, (IoSession.isClosing() == true), > while parsing the last packet from the server. It seems this is not now > the case. I will eventually get an IoHander.sessionClosing() callback, > but the undecoded message is left hanging out there with decodable() > returning false. > To hack this, I figure I could add a last "unknown content length" > ByteBuffer as a session attribute from MessageDecoder.decodable(), > (carefully acquire() and release() managed), and process it on > IoHandler.sessionClosing() manually. This seems kind of ugly and not > within the spirit of the Mina API. Any suggestions how to better handle > this? > My idea: > ======== > Ah, so.. in HTTP/1.0, 'EOC (end of connection)' can be a useful information > for decoding, but it is not informed to ProtocolDecoder, right? This is > certainly a problem. > For now, ProtocolDecoder.dispose () is invoked just before sessionClosed() is > invoked. So we could add a ProtocolDecoderOutput parameter to dispose() > method, but I think is not a good idea. Providing another method like > 'finishDecode()' would be better to separate the decoding code and the > resource management code. -- 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
