hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-148) Create AsyncNHttpServiceHandler & AsyncNHttpClientHandler
Date Mon, 18 Feb 2008 16:28:34 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569936#action_12569936
] 

Sam Berlin commented on HTTPCORE-148:
-------------------------------------

I agree that for incoming entities, the interfaces (especially BlockingHandler) are a little
cumbersome within AsyncNHttpHandler.  I took a little solace knowing that the work was basically
all handled internally, with the NBlockingHttpRequestListener doing the hard work internally,
and AsyncNHttpHandler knowing how to deal with it.  A simpler API could make that interaction
a lot nicer.

I'm not certain I agree that ContentListener should go.  Perhaps I just don't understand how
the API you listed would be used.  Could you describe that a little bit?  I don't see right
now how ConsumingNHttpEntitiy.consumeContent(Decoder, IOControl) fits in the picture.  It
also looks like the RequestHandler is now generating the consuming entity, as opposed to ServiceHandler
giving it to the RequestHandler?  If that's the case, it seems a little awkward -- I very
much like the idea of how all existing service handlers generate incoming entities internally
with the 'BasicXXX' class, because an incoming entity is really just a stream of bytes that
the outside world is just consuming.  Perhaps I'm just confused about how it would be used.

My current plan was to reuse ConsumingNHttpEntity w/ ContentListener within the client handler.
 That would allow large incoming responses to be consumed asynchronously (while allowing I/O
to be suspended if the incoming data couldn't be processed fast enough).  It could follow
the same route as this API change, and move the ContentListener into an additional method
within HttpRequestExecutionHandler, however I somewhat like the idea of installing the listener
immediately and then going right to that listener for updates (as opposed to having to find
what wants the data based on the context and then pushing the data to it).

Regarding ResponseListener & BlockingHandler -- I see those as being around purely for
interoperating with legacy blocking code, or as stop-gaps on the path towards full asynchronous
handling.  I don't think the API should be designed with those in mind, as they're inherently
against the spirit of the Async service handler.  The service handler could function extremely
well without them, though it would likely see a slower uptake in existing codebases.  The
use of NHttpResponseTrigger seems to be designed as a replacement for ResponseListener, however
in the majority of cases (either the incoming entitiy is handled asynchronously or there is
no incoming entity), there's no need for a response trigger.  As soon as the consumeContent
call returns, if the decoder is completed, there should be an outgoing entity available. 
(The reason this didn't work with the blocking listener was because consumeContent can be
called from one thread & return with a completed decoder, meanwhile the content is actually
used in another thread and it might take a bit for the response entity to be generated.)

I agree wholeheartedly on point 2.  There's no need for NHttpEntity at all.  I kept it just
because it seemed useful to describe non-blocking entities as one of the same.

Sorry for the lengthy reply!  I'm definitely not clear on how the patch or proposed APIs are
different with regards to pipelining, so that might changes things.




> Create AsyncNHttpServiceHandler & AsyncNHttpClientHandler
> ---------------------------------------------------------
>
>                 Key: HTTPCORE-148
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-148
>             Project: HttpComponents Core
>          Issue Type: New Feature
>          Components: HttpCore NIO
>    Affects Versions: 4.0-beta2
>            Reporter: Sam Berlin
>            Assignee: Oleg Kalnichevski
>         Attachments: changes.txt
>
>
> Attached is a patch for AsyncNHttpServiceHandler.  It actually works (as tested by running
& hitting it with IE.)  :)
> To test, run the example 'AsyncNHttpFileServer' in the examples directory or the TestAsyncNHttpHandlers
test.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message