I'm working in java (openjdk14) on a project that sends files to a webservice. The server takes its time to process this files so I need to set the TCP keepalive time in order to not lose the connection. Is there any way to set the TCP keepalive time in windows?
I'm using openjdk14 and Windows 10 Pro
I will appreciate any help
I found a way in linux using ExtendedSocketOptions but in Windows it seems that it's not supported:
`Socket sock = sf.createSocket(context);
sock.setOption(ExtendedSocketOptions.TCP_KEEPIDLE, 60);
sock.setOption(ExtendedSocketOptions.TCP_KEEPCOUNT, 75);
sock.setOption(ExtendedSocketOptions.TCP_KEEPINTERVAL, 3); `
Related
1) We have installed our Java application in Windows 2012 Server. After running for some time application started showing Connection Time out. We have set TCP Parameters MaxUserPort = 65534 and TcpTimedWaitDelay = 30.
We are facing the same issue, even after setting the parameters in windows registry. We have verified in our application, "There is no connection pool issue and no thread issue".
We are using JDK v6.0.29, Tomcat 7, MYSQL 5.5.
Apart from MaxUserPort and TcpTimedWaitDelay is there any other TCP parameters in Windows 2012 to improve performance of the server and our application.
2) At the same time we have found that ‘There is sluggishness in I/O process’.
Is there any registry parameters to improve I/O performance in the system.
Thank You.
I wrote a little java program that establishes a socket connection (port 23456) over TCP between a server (pong.java) and a client (ping.java). I start the server and then the client which sends ping and the server responds with pong. This happens 50 times.
This works all fine but now i want to shut this down using a SYN Flood DoS attack with hping3, but i can't get it to work. I can easily stop a file transfer running between the client and the server over SMB with the same DoS program. The server definitely gets the SYN packages- When i attack the same port the java socket connection uses it just shuts the attack down and the java program happily finishes the 50 loops. i can't figure out why. is there some protection in java or do sockets in java work different than a TCP exchange over SMB?
I do this for a network class and i just can't figure it out. I just attack myself between 3 VMs so no one will get harmed.
I can provide the source code or further information if needed.
Thanks a lot if anyone can help.
I don't know whether it fits or not, however I wrote a server-client app and more clients were trying to connect. As long as I used the Sun JRE, it worked. With the OpenJava, I was unable to get it work - only the first client connected, the others had to wait. I was unable to figure out why, and didn't really care - installed Sun (nowadays Oracle) JRE on the server and it run smooth. So if you use Linux and OpenJava, I suggest give it a try with Oracle's JRE.
Our Java application consists of a client and a server. In our production environment, establishing the connection takes a long time (~40 seconds).
We captured the network traffic using tcpdump and can see the following packets when the connection is established:
start client > server SYN
2 milliseconds later server < client SYN,ACK
38 *seconds* later client > server ACK
In our other environments, all three packets occur nearly instantaneously.
Can anyone suggest what might cause the 38 second delay, or suggest steps to diagnose it? Note that, because this is a production environment, it's hard for us to make diagnostic code changes.
Here are some details about our environment:
The client uses SocketConnector from Apache Mina 1.0.1, which internally uses java.nio.channel.SocketChannel.connect(..).
The client is running inside IBM WebSphere 7.0.0.17
Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
OS is AIX, version 6.1
aren't you running out of descriptor and/or your TCP accept queue is full ?
I need to create 1000 server sockets using Java. Somewhere between creating 600 and 700 sockets I'm getting this error:
05.04.2012 10:23:57 java.net.SocketException: No buffer space available (maximum connections reached?): listen at sun.nio.ch.ServerSocketChannelImpl.listen(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:127) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) at channelserver.NIOAppServer.initSelector(NIOAppServer.java:40) at channelserver.NIOAppServer.(NIOAppServer.java:27) at channelserver.NIOServer.main(NIOServer.java:433) at channelserver.NIOServer.main(NIOServer.java:438)
After that my computer reboots.
I've tried to edit the registry setting MaxUserPort = 65534 and MaxFreeTcbs = 2000, but it didn't help.
What else can I do?
On http://serverfault.com someone told me that it may be related to JDBC, but I connect to DB only once. I use SQLite.
Any suggestions?
on Windows XP have a limit on half-open connection to broke this rule you need to patch your tcpip.sys driver (but it's illigable) or using modern OS like Windows Vista/7 they haven't those limits.
Just in case someone would face this problem too.
Finally it seemed to me that it's just WinXP's problem. I've tried the same code with more RAM - results were the same. But when I've tried it on Win7, everything worked fine even with 1200 sockets.
So, WinXP is just not suitable for such tasks.
I have a java client program that uses mdns with service discovery to find its associated server. After much testing on a single network with Windows, Fedora 10, and Ubuntu 8.10, we delivered a test build to a customer. They report that the client and server never connect. They sent us a wireshark capture that shows the mdns packets have a TTL of 1 even though our code sets it to 32. When we test locally, the TTL is 32 just like we set it. The customer is using Redhat Enterprise 5.
I saw Java Multicast Time To Live is always 0 but it leaves me curious as to why that question asker has a TTL of 0, but mine is 1.
Did you check out the answer to Java Multicast Time To Live is always 0? This may fix your problem as well. The answer there references the answerer's blog entry.