hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: HLCA: client vs server
Date Wed, 19 Jan 2005 04:07:39 GMT
> So the connection manager on the client side implements a pool, while
> the connection manager on the server side implements a request queue.
> To me, "manager" implies a pool, so I would prefer a different name on
> the server side. But since I'm not a native english speaker, I may be
> off here. I guess that's why I wrote that we don't need a connection
> manager on the server side. A request queue is definitely useful ;-)

I would agree, a connection manager is a poor name.  The writing and 
reading of requests seems to fit more of a producer/consumer 
relationship.  In many ways neither the client nor the server really 
care about the connection.  Their only real interest in in the request.

> I would expect the connections that are not closed immediately go to
> a separate set. There they remain until they go stale, time out, or
> until the first data of the next request is available. Only then will
> a server connection go back to the request queue.
> In C or C++, one could try to set up a single blocking operation for
> all connections on hold. (Was that "select"? It's been too long.)
> In Java, I would use a polling thread.

Can't say much about the C++ side.  Unfortunately I never had the joy 
of doing any real work in C/C++ :)

Ideally a single blocking operation that returned when the next request 
is available would be best.  My knowledge of NIO is pretty minimal, but 
it seems like this should be an option.

Mike


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


Mime
View raw message