hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Lochart" <dloch...@gmail.com>
Subject Re: Persistent connections ?
Date Wed, 30 Aug 2006 20:45:05 GMT
On 8/30/06, Oleg Kalnichevski <olegk@apache.org> wrote:
> Actually as per RFC2616 Firefox always opens two connections with the
> target host if there's more than one entity to be retrieved.

So if there are say 7 entities then Firefox would use both connections to
get all 7?  Or should I expect to see more connections?

>  To my knowlege I am not explicitly closing the
> > connection as I am expecting more connections to come.
> You should be using DefaultConnectionReuseStrategy to determine if a
> connection should be kept alive or not. There are cases when HTTP agents
> may explicitly request the connection to be closed.

I am using DefaultConnectionReuseStrategy in both places.  (proxy ->
webserver) When I receive the response from the web server and then again
(proxy -> client) when the response is serialized.  The HttpService I
extended does it for me for the (proxy -> client) clase.

> >   If you look at the
> > ElementalHttpServer code you will see pretty much exactly what I am
> doing
> > when dealing with the client.  Eventually the ConnectionProcessorThread
> will
> > try to read from the socket again as the connections was kept open and I
> > will get a Socket Read error.
> >
> You are talking about a socket connected to the client host (incoming
> connection) or to the target host (outgoing connection)?

Here is the code snippet (its connection between the client and the proxy)
I realize this is just example code and that may be my current problem  but
my question is still valid as In this case I expect the connection to be
reused and I do not believe that handleRequest() will do a blocking read
(thus my timeout error)  any suggestions?

static class ConnectionProcessorThread extends Thread {

        private final HttpService httpservice;

        public ConnectionProcessorThread(final HttpService httpservice) {
            this.httpservice = httpservice;

        public void run() {
            _logger.debug("New connection thread");
            try {
                while (!Thread.interrupted() &&
!this.httpservice.isDestroyed() && this.httpservice.isActive()) {
                    _logger.debug("handleRequest() begin");
                    _logger.debug("handleRequest() end");
            } finally {
                _logger.debug("calling httpservice destroy()");
            _logger.debug("connection thread exiting");

In this case what should I do if my ResponseConnControl adds a connection
header to keep this connection alive?

> > 3)  Is it because its a proxy server and the browsers make new
> connections
> > to proxies vs reuse existing connections to web servers?
> >
> Are you implementing a transparent (reverse) proxy or a standard
> (caching) proxy? Did you actually have to tell the browser to connect
> via the proxy of yours or not?

Actually it is a content stream filtering proxy that will probably sit in
front of squid cache when I am done.  I am doing content filtering, tag
stripping etc as well as providing a flexible template design for specifying
classes of urls and being able to apply different rules to those classes.
We were using the Sun Proxy Server which claims to do all of this but after
I discovered and reported 3 bugs (2 of which were show stoppers and proved
the code is hardly tested) we decided to write our own and grow it over

I do see a ResponseConnControl which answers my other question.

Now is there a little write up or anything that discusses the various
interceptors or at least describes what is required and what is not and if
any ordering of them is required?  Any design cheat sheets as it were?



> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

What profits a man if he gains the whole world yet loses his soul?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message