Re: Sockets and Java NIO?
Does HttpClient make use of Java NIO when in a Java 1.4.x context? If not, is there any work being done in this direction? wherefor? it doesn't make sense since reading and writing to the socket is done in the thread, from which the methods are called. NIO would make sense, if the API of HttpClient would be somehow asynchronious. That would mean that you can drop a "Job" into a Queue and that it's executed in the background. As this is not the case, using NIO doesn't make any sense. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sockets and Java NIO?
Hi André, HttpClient does not make use of NIO. There are also no plans to add NIO support any time in the future. You are certainly welcome to contribute any code toward this goal though. Given the current architecture of HttpClient, and HttpConnection in particular, I think it may be difficult to add NIO support. Do you have any thoughts/suggestions about how this would best be done? Also, I'm wondering if there is any evidence that NIO will provide much of a benefit for HttpClient. Mike André-John Mas wrote: Hi, Does HttpClient make use of Java NIO when in a Java 1.4.x context? If not, is there any work being done in this direction? regards Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sockets and Java NIO?
Hi, Does HttpClient make use of Java NIO when in a Java 1.4.x context? If not, is there any work being done in this direction? regards Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS // NIO
The issue of custom DNS resolver has been discussed on several
occasions. The consensus was (if my memory does not fail me) that domain
name resolution was clearly out of HttpClient's scope. Instead we have
provided a way to plug in a custom DN resolution mechanism by supporting
virtual host names in the target host's configuration.
HostConfiguration hostconfig = new HostConfiguration();
hostconfig.setHost("127.0.0.1", "www.whatever.com", 80,
Protocol.getProtocol("http"));
HttpClient agent = new HttpClient();
agent.setHostConfiguration(hostconfig);
This can also be done on individual methods using
HttpMethod.getHostConfiguration().setHost(...).
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS // NIO
Clemens,
Please see my comments below
On Fri, 2003-07-25 at 19:24, Clemens Marschner wrote:
> Hi,
>
> there are two issues I would like to bring up that were mentioned in this
> list during the last months but were never resolved:
>
> 1. Java DNS handling as done by java.net.Socket is very inefficient for
>
> This could be avoided by issueing only the IP address to java.net.Socket and
> thus to HTTPClient. However, it is necessary to pass the host name to
> HTTPClient in order to resolve multiple host names per IP address within the
> HTTP request.
>
> Do you have any plans to plug in an external DNS resolver and create a
> Socket only with the IP address?
>
The issue of custom DNS resolver has been discussed on several
occasions. The consensus was (if my memory does not fail me) that domain
name resolution was clearly out of HttpClient's scope. Instead we have
provided a way to plug in a custom DN resolution mechanism by supporting
virtual host names in the target host's configuration.
HostConfiguration hostconfig = new HostConfiguration();
hostconfig.setHost("127.0.0.1", "www.whatever.com", 80,
Protocol.getProtocol("http"));
HttpClient agent = new HttpClient();
agent.setHostConfiguration(hostconfig);
> 2. Are there any people working on a NIO based version of HTTPClient? I saw
> some notes on this on a weblog, but haven't seen any results.
>
Our goal is to provide Java 1.2 compatibility as long as the project
reliant on HttpClient require it. That puts NIO support pretty much out
of question for a considerable period of time to come. This said,
however, we are planning to provide a means of plugging in a custom
HttpConnection implementation in 3.x release, which would allow NIO
based implementation to be used instead of official Java 1.2 compatible
one.
More good stuff will be coming in the 3.x release. It can well make
bearing with us worthwhile.
cheers
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DNS // NIO
Hi, there are two issues I would like to bring up that were mentioned in this list during the last months but were never resolved: 1. Java DNS handling as done by java.net.Socket is very inefficient for applications that open connections to many different hosts. This is due to a host name cache inside java.net.Socket. It contains a list of host names and the expiry time of each cache entry. Whenever a connection to a new host is made, the name is looked up in the cache. The first thing this cache does is iterate through the whole list of entries and kick out all expired entries. This means the operation uses O(number of cached hosts) time (and if I recall right, also memory, since the cache doesn't have an upper limit) each time that a socket connection is opened. This could be avoided by issueing only the IP address to java.net.Socket and thus to HTTPClient. However, it is necessary to pass the host name to HTTPClient in order to resolve multiple host names per IP address within the HTTP request. Do you have any plans to plug in an external DNS resolver and create a Socket only with the IP address? 2. Are there any people working on a NIO based version of HTTPClient? I saw some notes on this on a weblog, but haven't seen any results. Regards Clemens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NIO
I have been thinking along the same line. Unfortunately, HttpMethodBase and HttpConnection, which is a concrete class, are tightly coupled. They can't be easily decoupled. Another strategy would be to make HttpClient an interface, but unfortunately HttpConnction is being used directly by a few folks out there. There are numerous limitations of the current architecture we can't work around (at least nicely). Our strategy is to release 2.0 as soon as the existing HttpClient is reasonably stable and bug-free and move past current API compatibility where we would have a chance to improve the overall design Cheers Oleg On Thu, 2003-03-27 at 18:49, Sergio Berna wrote: > Dont worry it was just a philosophical question. > > Do you think it would be possible to extend a new ConnectionManager, > HttpConnection and SocketFactory to include NIO as a plugin without breaking > backwards compatibility? > > > > -Mensaje original- > De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 27 de marzo de 2003 18:32 > Para: Commons HttpClient Project > Asunto: Re: NIO > > > HttpClient is being used by a few Apache projects that only recently > abandoned 1.1 compatibility (after long and heated debates). I am afraid > if we want to play nicely with those folks, JDK 1.4 is no-go for years > to come. > > Oleg > > On Thu, 2003-03-27 at 18:15, Sergio Berna wrote: > > One more question, but this one is just philosophy and self knowledge. > > > > Do you have any plans to work with NIO in some way? > > I suppose it presents mainly problems with backwards compatibility > althought > > it promises higher control and efficiency over socket streams and several > > things such as socketchannels and shared buffers would be the best way of > > creating a multithreaded connection manager. > > > > Have you had any discussion about this? > > > > Thx for your time. > > > > Sergio. > > > > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NIO
Dont worry it was just a philosophical question. Do you think it would be possible to extend a new ConnectionManager, HttpConnection and SocketFactory to include NIO as a plugin without breaking backwards compatibility? -Mensaje original- De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Enviado el: jueves, 27 de marzo de 2003 18:32 Para: Commons HttpClient Project Asunto: Re: NIO HttpClient is being used by a few Apache projects that only recently abandoned 1.1 compatibility (after long and heated debates). I am afraid if we want to play nicely with those folks, JDK 1.4 is no-go for years to come. Oleg On Thu, 2003-03-27 at 18:15, Sergio Berna wrote: > One more question, but this one is just philosophy and self knowledge. > > Do you have any plans to work with NIO in some way? > I suppose it presents mainly problems with backwards compatibility althought > it promises higher control and efficiency over socket streams and several > things such as socketchannels and shared buffers would be the best way of > creating a multithreaded connection manager. > > Have you had any discussion about this? > > Thx for your time. > > Sergio. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO
HttpClient is being used by a few Apache projects that only recently abandoned 1.1 compatibility (after long and heated debates). I am afraid if we want to play nicely with those folks, JDK 1.4 is no-go for years to come. Oleg On Thu, 2003-03-27 at 18:15, Sergio Berna wrote: > One more question, but this one is just philosophy and self knowledge. > > Do you have any plans to work with NIO in some way? > I suppose it presents mainly problems with backwards compatibility althought > it promises higher control and efficiency over socket streams and several > things such as socketchannels and shared buffers would be the best way of > creating a multithreaded connection manager. > > Have you had any discussion about this? > > Thx for your time. > > Sergio. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NIO
One more question, but this one is just philosophy and self knowledge. Do you have any plans to work with NIO in some way? I suppose it presents mainly problems with backwards compatibility althought it promises higher control and efficiency over socket streams and several things such as socketchannels and shared buffers would be the best way of creating a multithreaded connection manager. Have you had any discussion about this? Thx for your time. Sergio.
