[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
