[jira] Commented: (DIRMINA-248) ProtocolDecoder should get notified when a connection is closed.

["Randy Watler (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/DIRMINA-248?page=comments#action_12431790 ] 
            
Randy Watler commented on DIRMINA-248:
--------------------------------------

Right. Clearly, it seems best to somehow get this information into the decoder before sessionClosed() is invoked so that it can trigger a IoHandler.messageReceived() callback. I am currently using a MessageDecoder with the Demux support, so I'd like to see the notification propagated through that set of APIs as well.

I assume that somehow knowing this is the last packet from the server and arranging for IoSession.isClosing() to reflect this fact is not feasible. If there was a non blocking way to query the session for that condition, that would work nicely within the existing protocol. 

I am using 0.9.4, so upgrading to svn HEAD is not too much of an issue for me. However, I'd like to know how you would hack 0.9.4 to make it work in the event I run into trouble with a snapshot.

> 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
>             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