users@jersey.java.net

[Jersey] Re: Slow redirects using HttpUrlConnection

From: Gili <cowwoc_at_bbs.darktech.org>
Date: Wed, 26 Oct 2011 06:12:29 -0700 (PDT)

Gili wrote:
>
>
> Gili wrote:
>>
>>
>> Oleksiy Stashok-2 wrote:
>>>
>>> On 08/23/2011 04:00 PM, Gili wrote:
>>>> Gili wrote:
>>>>> Does anyone have any idea on what's going on? 500ms seems extremely
>>>>> slow
>>>>> for something as simple as URL redirects, especially when all
>>>>> communication is taking place on localhost.
>>>>>
>>>> I tracked it down to this stack-trace:
>>>>
>>>> SocketInputStream.read() invoked by
>>>> BufferedInputStream.fill() invoked by
>>>> BufferedInputStream.read1() invoked by
>>>> BufferedInputStream.read() invoked by
>>>> HttpClient.parseHTTPHeader() invoked by
>>>> HttpURLConnection.getInputStream() invoked by
>>>> HttpURLConnection.getResponseCode() invoked by
>>>> URLConnectionClientHandler._invoke()
>>>>
>>>> Still no idea why this is happening...
>>> Looks like at this step client tries to read more data from the server,
>>> so may be it's not really a client problem.
>>> What are you using on the server side?
>>>
>>> You may also try to capture the network traffic/stats to check where the
>>> actual delay appears.
>>>
>>> WBR,
>>> Alexey.
>>>
>>
>> Right. Both the client and server seem to hint the other is at fault. Is
>> there a tool I can run in the middle that will prove once and for all
>> when each request / response actually gets sent?
>>
>> Thanks,
>> Gili
>>
>
> I ended up using Fidler HTTP proxy and got the following results:
>
> ClientConnected: 16:27:39.774
> ClientBeginRequest: 16:27:39.774
> ClientDoneRequest: 16:27:39.774
> Determine Gateway: 0ms
> DNS Lookup: 0ms
> TCP/IP Connect: 0ms
> HTTPS Handshake: 0ms
> ServerConnected: 16:27:39.774
> FiddlerBeginRequest: 16:27:39.774
> ServerGotRequest: 16:27:39.774
> ServerBeginResponse: 16:27:40.279
> ServerDoneResponse: 16:27:40.279
> ClientBeginResponse: 16:27:40.279
> ClientDoneResponse: 16:27:40.279
>
> It looks like the server is at fault. I'm using Jetty so I'm going to
> investigate further.
>

For what it's worth, the problem turned out to be the NOD32 HTTP scanner.
Upgrading to the latest version of NOD32 fixed the problem.

Gili

--
View this message in context: http://jersey.576304.n2.nabble.com/Slow-redirects-using-HttpUrlConnection-tp6712832p6932593.html
Sent from the Jersey mailing list archive at Nabble.com.