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
constructor.
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
florent
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pingwy
27, rue des arènes
49100 Angers
