On Tue, 2013-02-05 at 03:26 -0800, Oliver Lorenz wrote: > Thanks for your reply Oleg. > > You wrote: > > > Is there a reason for using such an outdated version of HttpClient? > > We have started to use it when it came out, and did not have a direct need > to upgrade. But we will plan for that. > > > > As far as i understood the execute(), it blocks until the whole stream > > is > > > read from the socket. Is that not the case? Can the performance of > > writeTo() > > > be in some way depending on the network? > > > > Absolutely. Smaller messages may fit into the network buffer in their > > entirety. Larger messages most likely are transmitted with several > > packets. Delivery of those packets can be affected by network > > nstability or congestion. > > > >Oleg > > Of course I am aware of the fact that the network affects the performance of > execute(), but I expected all packets to be transferred once execute() > returns?
Usually this is the case unless the server responds out of sequence with an early response without having received the entire request message. > My question targets especially the call writeTo(). From what I can > see, writeTo() just copies bytes from one place to another, and, in the end, > calls the connection manager to release the connection. That other place is the network stack and write operations can block indefinitely if the network stack is unable to flush internal output buffer for some reason. > So can even > writeTo() have a varying performance based on the network? > There is no guarantee that the network stack can flush the output buffer instantaneously. The speed with which the network stack is able to write packages out is likely to vary. Some packages may even need to be re-transmitted, and so on. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
