[ 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

        

Reply via email to