1

I got very similar behaviour as described in HttpURLConnection getInputStream() has one second delay: getting the InputStream of a http-connection in Java causes a delay at least 500ms. InputStreams were closed properly. Using the apache httpclient implementation resolves the problem, too. Unfortunaltely, the replacement is not suitable in each of my use cases.

Additionally, the delay does not show up in every setting. The observations i made so far are as follows:

  • Using the httpclient library works like a charm
  • Using Windows Server 2012 R2 on the server side does not cause delays neither with W7 Professional nor W7 Enterprise
  • Java version on client side does not matter (32bit/64bit, 7/8)
  • Using Windows 7 Enterprise or Linux on the client side works like a charm
  • Using Windows 7 Professional on the client side and a Linux box on the host side causes (at least) 500ms delays

Futhermore, it is no solution to condemn Linux on the server side wholesale as somewhere else, the problem does not show up using the Windows 7 Professional edition.

I monitored the network traffic with wireshark to find differences without success: the delay happens on the client side after the response got received entirely.

Finally, the question(s): exists a limitation in (the network stack of) Windows 7 Professional that causes this behaviour? Is it possible to tweak the Windows settings so the delay does not happen?

Community
  • 1
  • 1
grmpfl
  • 21
  • 4

2 Answers2

3

You need to understand that the TCP connection isn't created until you call one of:

  • getOutputStream()
  • getInputStream()
  • getErrorStream()
  • getResponseCode()

The delay you're seeing is therefore the TCP handshake latency. There's nothing you can do about that in your code.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thank you for your response! But i think i need to clarify some thing: getInputStream() is called, the TCP handshake as well as the request and the response by the server happens instantly after calling getInputStream() (verified by Wireshark; aktually, i'm calling getResponseCode() which itself calls getInputStream()). The delay happens _after_ the last network package got received. – grmpfl Apr 15 '15 at 10:05
  • So what's your question? I answered the one you asked: '`getInputStream()` causes delay'. – user207421 Apr 15 '15 at 10:20
  • I got the delay on Windows 7 Professional only, but not on the Enterprise Edition. I want to know if there is something i can do about it. – grmpfl Apr 15 '15 at 11:05
  • Ok, i cannot do something in my code. But as there is no problem with the Enterprise Edition of Windows 7, do you know whether this issue is a limitation of Windows 7 Professional or does exist a Windows system setting to eliminate the delay? – grmpfl Apr 15 '15 at 12:18
  • The delay is the TCP handshake latency and also the time to transmit the request, create the response at the server, and transmit the response. There is nothing you can do about any of those things at the client end. – user207421 Oct 29 '17 at 07:07
  • Thanks for your comment and effort (even after that amount of time)! The problem got solved (see my answer). – grmpfl Oct 31 '17 at 01:16
1

I honestly forgot about this question but as it was solved a couple of weeks later, i want to provide the backgrounds.

The problem was a misconfigured anti virus program (avira) on the client side. That scanner monitored the http traffic on the typical ports 80, 443 and 8080 adding the delay on the client side.

The server side of the software running on windows servers was configured to listen on port 9090 which the anti virus program ignored completely.

So the solution was to tell the anti virus program to not scan the http traffic.

grmpfl
  • 21
  • 4