It's on my virtual 'to-do' list (along with many other things [Sigh]).
Feel free to file a bug report and attach a patch against CVS HEAD,
though.
Oleg
On Thu, 2004-04-08 at 21:29, Sam Berlin wrote:
> Regarding point 4, it might be worthwhile to use reflection on newer
> JVMs so that the controller thread isn't necessary. An example of this
> is:
>
> //a) Conceptually, this code does the following:
> // SocketAddress addr=new InetSocketAddress(host,
> port);
> // Socket ret=new Socket();
> // ret.connect(addr, timeout);
> // return ret;
> // Unfortunately that causes compile errors on older
> versions
> // of Java. Worse, it may cause runtime errors if class
> loading
> // is not done lazily. (See chapter 12.3.4 of the Java
> Language
> // Specification.) So we use reflection.
> Class _socketClass = Class.forName("java.net.Socket");
> Class _socketAddressClass =
> Class.forName("java.net.SocketAddress");
> Class _connectMethod = _socketClass.getMethod("connect",
> new Class[] { _socketAddressClass, Integer.TYPE });
> Class socketAddress =
> Class.forName("java.net.InetSocketAddress");
> Class _inetAddressConstructor =
> socketAddress.getConstructor(new Class[] {
> String.class, Integer.TYPE
> });
> try {
> Socket ret = (Socket)_socketClass.newInstance();
>
> Object addr = _inetAddressConstructor.newInstance(
> new Object[] { host, new Integer(port) });
>
> _connectMethod.invoke(ret,
> new Object[] { addr, new Integer(timeout) });
> return ret;
> } catch (InvocationTargetException e) {
> Throwable e2 = e.getTargetException();
> throw (IOException)e2;
> } catch(InstantiationException e) {
> } catch(IllegalAccessException e) {
> }
>
> Thanks,
> Sam
>
>
> On Thursday, April 8, 2004, at 03:22 PM, Oleg Kalnichevski wrote:
>
> > Gil,
> > (1) First and foremost DO reuse HttpClient instances when using
> > multi-threaded connection manager. HttpClient class is thread-safe. In
> > fact there are no known problems with having just one instance of
> > HttpClient per application. Using a new instance of HttpClient for
> > processing each request totally defeats all the performance
> > optimizations we have built into HttpClient
> >
> > (2) Use multi-threaded connection manager in case you do not
> >
> > (3) Disable stale connection check
> >
> > (4) Do not use connect timeout which causes a controller thread to be
> > spawned per connection attempt
> >
> > Oleg
> >
> > On Thu, 2004-04-08 at 21:02, Alvarez, Gil wrote:
> >> We recently ported our url-hitting code from using java.net.* code to
> >> httpclient code. We use it in a high-volume environment (20 machines
> >> are
> >> hitting an external 3rd party to retrieve images).
> >>
> >>
> >>
> >>
> >>
> >> After the port, we saw a significant increase in cycles used by the
> >> machines, about 2-3 times (ie, the load on the boxes increased from
> >> using up 20% of the cpu, to about 50%-60% of the cpu.
> >>
> >>
> >>
> >> For each request, we instantiate an HttpClient object, and a GetMethod
> >> object, and shut things down afterwards.
> >>
> >>
> >>
> >> In order to reduce the use of cycles, what is the recommended
> >> approach?
> >>
> >>
> >>
> >> Thank you.
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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]
