Problem with connection via URLConnection

[Mulan]

I drive just load tests against a web application. Since it involves a problem, I've written a small test client, the 10 thread started, each opens in a loop, each a URLConnection to the web server (always the same URL on a bit of HTML comes back), the returned data reads, while time, measures the connection between flies and removal. A request typically takes about 200ms in the Intersection. Each thread runs through 50 iterations, so that 500 were sent at the end of request to the web application (which is not very much). Now it is so that each individual test run, sometimes for pretty much all the threads hang for 60 seconds, "stay" and then continue working but quite normal. The server returns the result of the request still correct to the client thread. The time is definitely here when connecting to server lost (InputStream is = con.getInputStream ()). Please help me in understanding this issue.! I am facing the problem with connection via URLConnection.

[X-Ray]

You should also make sure to read the stream completely resonse. If you do not reads this can lead to idle TCP connections. In case of a IOException additionally you should still read the error stream (at least a big attempt) and then again to catch the IOException. But anyways I am not getting your exact doubt. So it would be better if you illustrate your doubt clearly.

[Mulan]

Thanks for trying me to help. I am explaining my problem in detail. On the server I can not understand this loss of time, however. I measure where the time from the date on which gets passed to the listener socket to the socket, up to the date on which the processing of the request is completed. There will never consume more than 100-200 ms. I'm just a little perplexed, how can I get the problem on the track have (already a few hours Google used). I think the most important information is that there are ALWAYS those 60 seconds exactly, are lost ... Has anyone a hint, what could be there, or an idea how I could investigate the problem further? I use Java 1.6.0 under Windows XP. The server runs standalone. I start the client with Eclipse. The operating system set the TCP port range is> 50000 possible ports (there are after all only 500 requests is running). Server and client run the same computer. A Netstat in situations in which hangs a thread, showed no abnormalities. This means that the list of established TCP connections fit on one screen. Please respond...

[DllD]

You can also set the client side via system property keepalive time, like

http.keepAlive = <boolean>
default: true

and the max connections:

http.maxConnections = <int>
default: 5

Server, the default config of tomcat to be ok for your purposes (if it is tomcat on the server side).

[Mulan]

Unfortunately there is no Tomcat but a proprietary development of a customer. KeepAlive I will still pursue times. As I said: It is located on a connection. At each iteration, while a new URLConnection is instantiated. The time is then goes on con.getInputStream () lost. How is this in the fall? Typically, the HTTP connection but would have to be constructed absolutely new, right? This means that even if keep-alive would be activated during a previous connection would have to, but actually won a new connection can be established, is it? The data is read by the server and complete (and will always work as expected). It does no IO exception. It takes just 60 seconds, back to the con.getInputStream () method. Then everything runs as expected. That is, the data is read and closes the connection afterwards.

[Khushal]

Attempts to use URLConnection instead of the times following the HttpConnection Lib, so that you can also use the timeouts [HTTPConnection.setTimeout ()] set client-side, the Library serves as a simplification and extension of the URLConnection. I think that you might have got the hint..

[Mulan]

The proposal with the time-out has put me on the idea of opening the URLConnection to a port on which nothing is running. Apparently the problem is already the client side. I have a couple of times the test started with 5 threads that connect all against a port that is running on a server. Normally, each immediately get a Connect Exception. But sometimes it takes them 60 seconds mentioned above, comes to the exception. Here is the output of such a test run. Thread 0-3 were immediately returned to the exception. Thread 4 after about 60 seconds (the dots "." Mean every 5 seconds, the main thread checks every 5 seconds whether all the request threads are finished):
Start Test ...
Thread 0 started ...
Thread 1 started ...
Thread 2 started ...
Thread 3 started ...
Thread 4 started ...
.
3 + java.net.ConnectException
1 + java.net.ConnectException
0 + java.net.ConnectException
2 + java.net.ConnectException
.
.
.
.
.
.
.
.
.
.
.
.
4 + java.net.ConnectException
THREAD 4 -> 60 953

RESULTS:
Thread Index; NumIterations; numErrors; MinReqT; MaxReqT; AvgReqT
Thread 0, 1, 1, 1016, 1016, 1016
Thread 1, 1, 1, 1016, 1016, 1016
Thread 2, 1, 1, 1016, 1016, 1016
Thread 3, 1, 1, 984, 984, 984
Thread 4, 1, 1, 60 953, 60 953, 60 953
END!
Has anyone seen similar scenario..?? Can now of course be a problem with the JVM, or with the TCP pool of Windows XP. Does anyone have an idea?

[Kallol]

Whichever file, print, named pipe, or mail slot session that does not have any commotion is involuntarily disconnected after the AutoDisconnect time has terminated, the evasion for the AutoDisconnect time is 15 minutes. When the session is disconnected, one of the ten connections becomes accessible so that an additional user can attach to the Windows XP system therefore, lowering the AutoDisconnect time can help to diminish some of the problems that users may encounter with the ten-connection limit or the five-connection limit on a system that is not used profoundly for server rationale.

[Warner]

Even I think the same. In Windows XP Professional, the maximum ten (10) other computers to simultaneously connect over the network. This restriction is combined for all transports and protocols that use resources. For Windows XP Home Edition, limited to five (5) other computers to simultaneously connect over the network. This is the maximum number of simultaneous sessions from other computers to which the system can act as a host. This restriction does not apply to the use of administrative tools that are connected from a remote computer with the system. Whether this also applies to HTTP, I can not imagine but I also remember you had the fiddle for Internet Explorer in the registry for more downloads at the same time. Do try your Java client from a Linux environment.

[Allan.d]

Try it once with the Java console under / JAVA_HOME / bin / jconsole.exe. Start Eclipse and go directly to the debugging then start the console and pick from the current process. You see there are a few views deeper into the native call really brings it a lot nothing more. Otherwise you could be the VM before starting perhaps give to the 2 parameters, of course not with 60:

networkaddress.cache.ttl = 60
-Dsun.net.inetaddr.ttl = 60

[MELTRONICS]

I would like to recommend that you do not go well on the Java border; the problem is indeed the native calls to the network libraries. Maybe you can play with the MS Network Monitor to record a complete traffic and a look that you can exclude, in any case, the server is causing the problem.