hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NIO HttpCore - Can requestInput result in two new requests
Date Sat, 16 Aug 2008 18:26:00 GMT
On Sat, 2008-08-16 at 08:45 -0700, Rae Egli wrote:
> Oleg,
> Thanks for getting back so quickly.
> I came to the same conclusion last night after having an even closer look at the problem.
 However, it does seem that the reverseproxy example misunderstands that concept as well as
it cannot handle multiple connections before the response has been completed.

I do not think so. I just ran a simple test using Apache Benchmark with
20 concurrent connections and all looked quite okay to me. I put the
reverse proxy in front of a local Tomcat instance.

oleg@ubuntu:~$ ab -k -n 200 -c 20 http://localhost:8888/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Finished 200 requests

Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8888

Document Path:          /
Document Length:        8132 bytes

Concurrency Level:      20
Time taken for tests:   0.792359 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Keep-Alive requests:    200
Total transferred:      1661000 bytes
HTML transferred:       1626400 bytes
Requests per second:    252.41 [#/sec] (mean)
Time per request:       79.236 [ms] (mean)
Time per request:       3.962 [ms] (mean, across all concurrent
Transfer rate:          2047.05 [Kbytes/sec] received


> The code seems to assume a serialization of requests that isn't enforced by the architectures.

Again, I am not sure this is the case (unless I am missing something)

>   As likely many people, especially at this point with little documentation available,
use a more complex example as their introduction, a warning about the bugs in the example
might be in order.  

I know the API is not adequately documented. I do admit the reverse
proxy example is based on a over-simplistic architecture, as it is only
meant to demonstrate the basic usage of the API rather than to be a
fully functional proxy. At the same time I fail to see any major
architectural issues with it.

Am I still missing something?


> Obviously it would be even better if the example would reflect the non-blocking aspect
of the architecture but I know that would take some time.
> Thanks again.
> Rae
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

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

View raw message