You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Trustin Lee (JIRA)" <ji...@apache.org> on 2006/08/31 04:58:22 UTC
[jira] Created: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
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
[jira] Commented: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
Posted by "Randy Watler (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-248?page=comments#action_12447693 ]
Randy Watler commented on DIRMINA-248:
--------------------------------------
Just in case anyone is following this thread, this change did indeed allow MINA to process HTTP/1.0 requests nicely w/o a content length.
Thanks again Trustin!
> 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
[jira] Commented: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
Posted by "Randy Watler (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-248?page=comments#action_12432025 ]
Trustin Lee commented on DIRMINA-248:
-------------------------------------
I had to add the same method to MessageDecoder. I will take care of it.
> 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
[jira] Commented: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-248?page=comments#action_12432035 ]
Trustin Lee commented on DIRMINA-248:
-------------------------------------
Done.
> 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
[jira] Commented: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
Posted by "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
[jira] Resolved: (DIRMINA-248) ProtocolDecoder should get notified
when a connection is closed.
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ 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