[ http://issues.apache.org/jira/browse/DIRMINA-248?page=all ]
Trustin Lee resolved DIRMINA-248.
---------------------------------
Resolution: Fixed
Assignee: Trustin Lee
I checked in the fix. finishDecode() method has been added to ProtocolDecoder
interface. Please let me know if this works.
With 0.9.4, I can't think of an easy workaround.
> 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