hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Blondeau <fblond...@pingwy.com>
Subject Re: HttpClient time measurement
Date Fri, 21 Dec 2007 14:42:03 GMT
Thanks for your clear response,

Sorry for the response time (close to TimeOutException, no ? ;-) ), but 
I dived into
the internet searching for a method to collect time with sockets. I 
can't find any... that doesn't
lead to a new socket Implementation !!
I think that the only workaround with HttpClient (as it isn't 
core-implemented) is to create a new
SocketFactory since it is possible to declare it in the Protocol 

This socketFactory has to be in charge of collecting time datas.

You're right for the dynamic proxies, I thought there was a Socket 
interface elsewhere, I don't know why.

I really thought it was too low lewel, but SocketFactory seems to be the 
only place where you can collect some dns resolution time,
socket connect time, that is to say all socket methods related stuff... 
without breaking the HttpClient "philosophy"

I have to wait for the version 4.0. If I have some time, I'll check if I 
can help

Thanks again for your comments


Roland Weber a écrit :
> Hello Florent,
>> I've got a *real* need on Time Measurements in HttpClient, like Dns,
>> connect, pre transfer, start transfer and download times.
>> I've seen there was an improvement request (HTTPCLIENT-68) scheduled for
>> 4.0 beta1 .
>> I've managed to add my own time collection tool, but it's really an ugly
>> hack (changing socket factory, and collecting times when calling
>> to socket methods)
> That's what I would have done, too. If you feel that is too low in
> the abstraction hierarchy, you may want to add some code on the
> connection level.
>> and I'm not sure it will works well in multithreaded
>> connections...
> Why should it not? You'll have to pass the thread context into
> your output, or keep the output within the thread context. But
> I don't see where the problem should be. The TSCCM uses only a
> cleanup thread (which will become optional), everything else is
> handled by your application threads and accessible there.
>> So, is there a known workaround to cope with that thing ?
> Nothing known to me, but maybe others have some ideas.
>> I was thinking
>> about creating a socketListener with a dynamic proxy
> What do you mean with socketListener? A thread listens on
> server-side sockets, that won't help on the client side.
> Dynamic proxy might refer to java.lang.reflect.Proxy, but
> that works only for interfaces, while java.net.Socket is
> a class.
>> to intercept
>> socket method call to collect time before and after execution, but
>> intercepting all socket method calls will lead my app to a performance 
>> loose, no ?
> Depends on how much overhead the interception adds. You'll never
> get around the calls to System.currentTime(), no matter where
> you add your timing calls. Compared to the overhead for network
> I/O, I'd say a few more Java method calls won't hurt too bad.
> If there are some methods where the timing calls get in the way,
> you can still skip the timing for those.
>> If I can't avoid my ugly hack,  how much time will I have to wait before
>> seeing the httpclient 4.0 beta1 (or better the 4.0 final) running ?
> Client beta in the second half of 2008, the final about one year
> later. These are my personal guesses. You can speed up the process
> or improve the final API by contributing.
> cheers,
>   Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

27, rue des arènes
49100 Angers

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