hc-dev mailing list archives

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

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

Oleg Kalnichevski commented on HTTPCORE-148:
--------------------------------------------

Sam

I guess my main gripe is the HttpRequestHandler interface that implies blocking processing
of HTTP requests and does not seem to fit well. So, the essence of my proposal is to come
up a new NHttpRequestHandler interface instead of trying to work around the blocking nature
of HttpRequestHandler. Something along these lines: 

(1) AsyncNHttpServiceHandler receives an HTTP request
(2) if it is an entity enclosing request NHttpRequestHandler#entityRequest event fires and
the handler creates a custom instance of ConsumingNHttpEntity. There is no longer a need to
inject custom processing logic through ContentListener
(3) otherwise go to 5
(4) NHttpRequestHandler#entityContent event fires as long as there is still incoming content
to consume
(5) NHttpRequestHandler#handle event fires as soon as the incoming content has been fully
consumed or if the request does not enclose an entity. This method does not have to trigger
a response. Think of situations when the request needs to be dispatched through a different
transport to a different target server and this may take quite a while.
(6) At some point of time NHttpResponseTrigger#commit is called to submit the response. 

I am fine with keeping ContentListener if you like it better, but I personally tend to prefer
to provide a custom implementation of ConsumingNHttpEntity instead of injecting some all the
processing logic through ContentListener. But that is just my personal, somewhat different
way of looking at things. It does not have to be that way.

The main motivating factor for proposing these API changes is that I kind of think we might
be able to simulate the functionality of both the buffering and throttling service handlers
on top of AsyncNHttpServiceHandler, which would be quite nice.

Does this all sound completely off base?

Oleg

> 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