We have a Webstart client that communicates to the server by sending serialized objects over HTTPS using java.net.HttpsURLConnection.
Everything works perfectly fine on my local machine and on test servers located in our office, but I'm experiencing a very, very strange issue which is only occurring on our production and staging servers (and sporadically at that). The main difference I know of between those servers and the ones in our office is that they are located elsewhere and client-server communication with them is considerably slower, but it worked fine for a long time in production prior to this as well.
Anyway, here's what's happening:
The client, after setting options such as read timeout and properties such as Content-Type on the HttpURLConnection, calls getOutputStream() on it to get the stream to write to.
At this point, from what I can tell, the client hangs for some period of time.
The client then throws the following exception:
java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(Unknown Source)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.New(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source)
Note that this is not a SocketTimeoutException, which the connect() method on HttpURLConnection says it throws if the timeout expires before a connection can be established. Also, when this happens I am able to call conn.getResponseCode() and I get a response code of 200.
On the server side, an EOFException is thrown in ObjectInputStream's constructor, which tries to read the serialization header but fails because the client never gets the OutputStream to write to.
In case it helps, here are the calls being made on the HttpsURLConnection prior to the call to getOutputStream() (edited to show only the calls being made rather than the whole structure of the code doing this):
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setUseCaches(false);
conn.setReadTimeout(30000);
conn.setRequestProperty("Cookie", cookie);
conn.setDoOutput(true);
conn.setRequestProperty("Content-Type", "application/x-java-serialized-object");
conn.getOutputStream();
The thing is, I have no idea how any of this could be happening, especially given that it only happens occasionally (no clear pattern of activity that I can tell) and even then only when there's (relatively) high latency between the client and the server.
Given what I've been able to find so far about java.net.ConnectException: Connect timed out, I wondered if it weren't some network or firewall issue on the network our servers are running on... but that doesn't make much sense to me given that the request is clearly getting through to the servlet. Also, other apps running on the same network have not reported similar issues.
Does anyone have any idea what the cause of this could be, or even what I should investigate?
We have come across these in a similar case to yours. Usually at high load and not easy to reproduce on test. Have not fixed it yet but this is the steps we went through.
If it's a firewall issue, we would get a Connection Refused or the SocketTimeout exception.
1) Are you able to track these requests in the access log on the server - do they show an HTTP status 200 or 404 or something else? In our case, the server (IIS in this case) logs showed the client closed the connection and not the server. So that was a mystery.
Update: If the client always gets a 200, then the server has actually sent back some response but I suspect the response byte-size (if this is recorded in the access logs) will show a different value from that of the normal response size for that request.
If it shows the same size of response, then you have a (may be not plausible) condition that the server actually responded correctly but the client did not get the response back because the connection terminated somewhere in between.
2) The network admin teams looked at the TCP/IP traffic to determine which end (or intermediate router) is terminating the HTTP / TCP-IP conversation. And once we understand which end is terminating the connection is to look at why. Someone knowledgable enough could run snoop
3) Is there a max number of requests configured/restricted on the server - and is that throttling your connections?
4) Are there any intermediate load balancers at which requests could be dropped?
Update: One more thing we wanted to, but did not complete is to create a static route between client and server to reduce the number of hops in between and ensure no network related connection drops. See http://en.wikipedia.org/wiki/Static_routing
5) Another suggestion is setting the ConnectTimeout too to see if these work with a higher value.
Update: You might want to try conn.getErrorStream()
Returns the error stream if the
connection failed but the server sent
useful data nonetheless. If the
connection was not connected, or if
the server did not have an error while
connecting or if the server had an
error but no error data was sent, this
method will return null.
6) Could also try taking a set of thread dumps on the server 5 seconds apart, to see if any thread shows these incoming requests on the server.
Update: As of today we learnt to live with this problem, because we totalled the failure rate to be 200-300 out of 400,000 requests per day which is 0.00075 %
We also experience sporadic timeouts when using it on our servers. We are able to fix it with two things:
Use specific ContentLength via setFixedLengthStreamingMode (brought down the error rate from ~150 to 10)
Retry if a timeout occurs (Error rate from 10 to 0. After max. one retry everything went through)
pseudo code:
//set timeouts to 6s
try{
//open connection here and write etc.
//use a timeout of 6s (since retry is in place)
}
catch (java.io.InterruptedIOException e) {
//read- or connection time out try again
}
Another theory why this is happening could be the following:
In the documentation of the HttpURLConnection/HttpsURLConnection one can read the following:
Each HttpURLConnection instance is used to make a single request but
the underlying network connection to the HTTP server may be
transparently shared by other instances.
So now calling close() only would be ok but also calling disconnect() would terminate the socket for the other users / transparently shared connections which would then run into a SocketTimeOut after the timeout period is reached.
Related
The exception is thrown using Apache FTPClient in LOCAL_PASSIVE_MODE. The process is running from a PC in a remote site over a satellite connection which I know to be less than stable. The same code works flawlessly over a stable connection to the same server, but I'm not sure if the difference comes from the stability of the connection, or the speed (ie, server configured timeouts)
My questions are as follows :
Is it necessarily the case that the connection was closed by the remote host (as stated in the exception), or is it possible that an interupted internet connection will generate the same exception ?
If it is true that an interupted internet connection will cause this exception how can I parameterize the FTPClient, or the underlying Socket to retry and resume the connection ?
How can I test if the connection was closed by the remote server or interupted ?
The FTPClient is configured for :
Connection timeout : 10 minutes
Data timeout : 10 minutes
Keep alive : enabled
Keep alive signals sent every 10 seconds
Keep alive reply from server timeout : 10 minutes
FTP buffer size : 1024 x 1024
I am waiting to receive the server configuration file and the server logs.
The stack trace is as follows :
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:317)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:45)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:683)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:659)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:648)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1120)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Is it necessarily the case that the connection was closed by the remote host (as stated in the exception), or is it possible that an interupted internet connection will generate the same exception?
No. The localhost received an RST from the peer. If the Internet connection was interrupted this would cause the local TCP to abort the connection, eventually, with a different message, such as 'software caused connection abort' or 'the connection was aborted by the software in your local host', whatever the exact wording is on your system. If it says 'by the remote host', it means it.
If it is true that an interupted internet connection will cause this exception
It isn't.
how can I parameterize the FTPClient, or the underlying Socket to retry and resume the connection?
I can't answer for the FTPClient, but a Socket that has had this exception is dead and must be closed. It cannot retry anything.
It would be more to the point to examine why the peer aborted the connection. For example, you may be violating an upload-size limit.
How can I test if the connection was closed by the remote server or interrupted?
Via the error message, unfortunately. They could have mapped the various errno values that can arise in sockets to different IOException or indeed SocketException subclasses, but they only did so in a few cases, such as ConnectException, SocketTimeoutException, ...
Given this stack trace snippet
Caused by: java.net.SocketException:
Software caused connection abort:
socket write error at
java.net.SocketOutputStream.socketWrite0(Native
Method)
I tried to answer the following questions:
What code is throwing this exception? (JVM?/Tomcat?/My code?)
What causes this exception to be thrown?
Regarding #1:
Sun's JVM source doesn't contain this exact message, but I think the text Software caused connection abort: socket write error is from the native implementation of SocketOutputStream:
private native void socketWrite0(FileDescriptor fd, byte[] b, int off,
int len) throws IOException;
Regarding #2
My guess is that it is caused when the client has terminated the connection, before getting the full response (e.g. sent a request, but before getting the full response, it got closed / terminated / offline)
Questions:
Are the above assumptions correct (#1 and #2)?
Can this be diffrentiated from the situation: "could not write to the client, due to a network error on the server side"? or would that render the same error message?
And most important: Is there an official document (e.g from Sun) stating the above?
I need to have a proof that this stack trace is the socket client's "fault", and there is nothing that the server could have done to avoid it. (except catching the exception, or using a non Sun JVM SocketOutputStream, though both don't really avoid the fact the client has terminated)
This error can occur when the local network system aborts a
connection, such as when WinSock closes an established connection
after data retransmission fails (receiver never acknowledges data sent
on a datastream socket).
See this MSDN article. See also Some information about 'Software caused connection abort'.
The java.net.SocketException is thrown when there is an error creating or accessing a socket (such as TCP). This usually can be caused when the server has terminated the connection (without properly closing it), so before getting the full response. In most cases this can be caused either by the timeout issue (e.g. the response takes too much time or server is overloaded with the requests), or the client sent the SYN, but it didn't receive ACK (acknowledgment of the connection termination). For timeout issues, you can consider increasing the timeout value.
The Socket Exception usually comes with the specified detail message about the issue.
Example of detailed messages:
Software caused connection abort: recv failed.
The error indicates an attempt to send the message and the connection has been aborted by your server. If this happened while connecting to the database, this can be related to using not compatible Connector/J JDBC driver.
Possible solution: Make sure you've proper libraries/drivers in your CLASSPATH.
Software caused connection abort: connect.
This can happen when there is a problem to connect to the remote. For example due to virus-checker rejecting the remote mail requests.
Possible solution: Check Virus scan service whether it's blocking the port for the outgoing requests for connections.
Software caused connection abort: socket write error.
Possible solution: Make sure you're writing the correct length of bytes to the stream. So double check what you're sending. See this thread.
Connection reset by peer: socket write error / Connection aborted by peer: socket write error
The application did not check whether keep-alive connection had been timed out on the server side.
Possible solution: Ensure that the HttpClient is non-null before reading from the connection.E13222_01
Connection reset by peer.
The connection has been terminated by the peer (server).
Connection reset.
The connection has been either terminated by the client or closed by the server end of the connection due to request with the request.
See: What's causing my java.net.SocketException: Connection reset?
I have seen this most often when a corporate firewall on a workstation/laptop gets in the way, it kills the connection.
eg. I have a server process and a client process on the same machine. The server is listening on all interfaces (0.0.0.0) and the client attempts a connection to the public/home interface (note not the loopback interface 127.0.0.1).
If the machine is has its network disconnected (eg wifi turned off) then the connection is formed. If the machine is connected to the corporate network (directly or vpn) then the connection is formed.
However, if the machine is connected to a public wifi (or home network) then the firewall kicks in an kills the connection. In this situation connecting the client to the loopback interface works fine, just not to the home/public interface.
Hope this helps.
To prove which component fails I would monitor the TCP/IP communication using wireshark and look who is actaully closing the port, also timeouts could be relevant.
For anyone using simple Client Server programms and getting this error, it is a problem of unclosed (or closed to early) Input or Output Streams.
Have you checked the Tomcat source code and the JVM source ? That may give you more help.
I think your general thinking is good. I would expect a ConnectException in the scenario that you couldn't connect. The above looks very like it's client-driven.
I was facing the same issue.
Commonly This kind of error occurs due to client has closed its connection and server still trying to write on that client.
So make sure that your client has its connection open until server done with its outputstream.
And one more thing, Don`t forgot to close input and output stream.
Hope this helps.
And if still facing issue than brief your problem here in details.
Had an SSLPoke.bat (SSL troubleshooting script) window script that was getting this error despite importing the correct certificates into the cacerts trustore.
C:\Java\jdk1.8.0_111\jre\lib\security>SSLPoke.bat
C:\Java\jdk1.8.0_111\jre\lib\security>"C:\jdk1.8.0_101\jre\bin\java"
`SSLPoke tfs.corp.****.com 443`
java.net.SocketException: Software caused connection abort: recv failed
`at java.net.SocketInputStream.socketRead0(Native Method)`
`at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)`
`at java.net.SocketInputStream.read(SocketInputStream.java:170)`
`at java.net.SocketInputStream.read(SocketInputStream.java:141)`
`at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)`
`at sun.security.ssl.InputRecord.read(InputRecord.java:503)`
`at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)`
`at sun.security.ssl.SSLSocketImpl.performInitialHandshake
(SSLSocketImpl.java:1375)`
`at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)`
`at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)`
`at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)`
`at SSLPoke.main(SSLPoke.java:28)`
I then checked some old notes about some network changes at my job. We would
need in some cases to add the JVM parameter
-Djava.net.preferIPv4Stack=true to make connections to certain machines
in our network to avoid this error.
C:\Java\jdk1.8.0_111\jre\lib\security>"C:\Java\jdk1.8.0_111\bin\java"
**-Djava.net.preferIPv4Stack=true** SSLPoke tfs.corp.****.com 443
Successfully connected
The code for SSLPoke can be downloaded from here:
https://gist.github.com/4ndrej/4547029
This error happened to me while testing my soap service with SoapUI client, basically I was trying to get a very big message (>500kb) and SoapUI closed the connection by timeout.
On SoapUI go to:
File-->Preferences--Socket Timeout(ms)
...and put a large value, such as 180000 (3 minutes), this won't be the perfect fix for your issue because the file is in fact to large, but at least you will have a response.
Closed connection in another client
In my case, the error was:
java.net.SocketException: Software caused connection abort: recv failed
It was received in eclipse while debugging a java application accessing a H2 database. The source of the error was that I had initially opened the database with SQuirreL to check manually for integrity. I did use the flag to enable multiple connections to the same DB (i.e. AUTO_SERVER=TRUE), so there was no problem connecting to the DB from java.
The error appeared when, after a while --it is a long java process-- I decided to close SQuirreL to free resources. It appears as if SQuirreL were the one "owning" the DB server instance and that it was shut down with the SQuirreL connection.
Restarting the Java application did not yield the error again.
config
Windows 7
Eclipse Kepler
SQuirreL 3.6
org.h2.Driver ver 1.4.192
In the situation explained below, client side will throw such an exception:
The server is asked to authenticate client certificate, but the client provides a certificate which Extended Key Usage doesn't support client auth, so the server doesn't accept the client's certificate, and then it closes the connection.
My server was throwing this exception in the pass 2 days and I solved it by moving the disconnecting function with:
outputStream.close();
inputStream.close();
Client.close();
To the end of the listing thread.
if it will helped anyone.
In my case, I developped the client and the server side, and I have the exception :
Cause : error marshalling arguments; nested exception is:
java.net.SocketException: Software caused connection abort: socket
write error
when classes in client and server are different. I don't download server's classes (Interfaces) on the client, I juste add same files in the project.
But the path must be exactly the same.
For example, on the server project I have java\rmi\services packages with some serviceInterface and implementations, I have to create the same package on the client project. If I change it by java/rmi/server/services for example, I get the above exception.
Same exception if the interface version is different between client and server (even with an empty row added inadvertently ... I think rmi makes a sort of hash of classes to check version ... I don't know...
If it could help ...
I was facing the same problem with wireMock while mocking the rest API calls.
Earlier I was defining the server like this:
WireMockServer wireMockServer = null;
But it should be defined like as shown below:
#Rule
public WireMockRule wireMockRule = new WireMockRule(8089);
Given this stack trace snippet
Caused by: java.net.SocketException:
Software caused connection abort:
socket write error at
java.net.SocketOutputStream.socketWrite0(Native
Method)
I tried to answer the following questions:
What code is throwing this exception? (JVM?/Tomcat?/My code?)
What causes this exception to be thrown?
Regarding #1:
Sun's JVM source doesn't contain this exact message, but I think the text Software caused connection abort: socket write error is from the native implementation of SocketOutputStream:
private native void socketWrite0(FileDescriptor fd, byte[] b, int off,
int len) throws IOException;
Regarding #2
My guess is that it is caused when the client has terminated the connection, before getting the full response (e.g. sent a request, but before getting the full response, it got closed / terminated / offline)
Questions:
Are the above assumptions correct (#1 and #2)?
Can this be diffrentiated from the situation: "could not write to the client, due to a network error on the server side"? or would that render the same error message?
And most important: Is there an official document (e.g from Sun) stating the above?
I need to have a proof that this stack trace is the socket client's "fault", and there is nothing that the server could have done to avoid it. (except catching the exception, or using a non Sun JVM SocketOutputStream, though both don't really avoid the fact the client has terminated)
This error can occur when the local network system aborts a
connection, such as when WinSock closes an established connection
after data retransmission fails (receiver never acknowledges data sent
on a datastream socket).
See this MSDN article. See also Some information about 'Software caused connection abort'.
The java.net.SocketException is thrown when there is an error creating or accessing a socket (such as TCP). This usually can be caused when the server has terminated the connection (without properly closing it), so before getting the full response. In most cases this can be caused either by the timeout issue (e.g. the response takes too much time or server is overloaded with the requests), or the client sent the SYN, but it didn't receive ACK (acknowledgment of the connection termination). For timeout issues, you can consider increasing the timeout value.
The Socket Exception usually comes with the specified detail message about the issue.
Example of detailed messages:
Software caused connection abort: recv failed.
The error indicates an attempt to send the message and the connection has been aborted by your server. If this happened while connecting to the database, this can be related to using not compatible Connector/J JDBC driver.
Possible solution: Make sure you've proper libraries/drivers in your CLASSPATH.
Software caused connection abort: connect.
This can happen when there is a problem to connect to the remote. For example due to virus-checker rejecting the remote mail requests.
Possible solution: Check Virus scan service whether it's blocking the port for the outgoing requests for connections.
Software caused connection abort: socket write error.
Possible solution: Make sure you're writing the correct length of bytes to the stream. So double check what you're sending. See this thread.
Connection reset by peer: socket write error / Connection aborted by peer: socket write error
The application did not check whether keep-alive connection had been timed out on the server side.
Possible solution: Ensure that the HttpClient is non-null before reading from the connection.E13222_01
Connection reset by peer.
The connection has been terminated by the peer (server).
Connection reset.
The connection has been either terminated by the client or closed by the server end of the connection due to request with the request.
See: What's causing my java.net.SocketException: Connection reset?
I have seen this most often when a corporate firewall on a workstation/laptop gets in the way, it kills the connection.
eg. I have a server process and a client process on the same machine. The server is listening on all interfaces (0.0.0.0) and the client attempts a connection to the public/home interface (note not the loopback interface 127.0.0.1).
If the machine is has its network disconnected (eg wifi turned off) then the connection is formed. If the machine is connected to the corporate network (directly or vpn) then the connection is formed.
However, if the machine is connected to a public wifi (or home network) then the firewall kicks in an kills the connection. In this situation connecting the client to the loopback interface works fine, just not to the home/public interface.
Hope this helps.
To prove which component fails I would monitor the TCP/IP communication using wireshark and look who is actaully closing the port, also timeouts could be relevant.
For anyone using simple Client Server programms and getting this error, it is a problem of unclosed (or closed to early) Input or Output Streams.
Have you checked the Tomcat source code and the JVM source ? That may give you more help.
I think your general thinking is good. I would expect a ConnectException in the scenario that you couldn't connect. The above looks very like it's client-driven.
I was facing the same issue.
Commonly This kind of error occurs due to client has closed its connection and server still trying to write on that client.
So make sure that your client has its connection open until server done with its outputstream.
And one more thing, Don`t forgot to close input and output stream.
Hope this helps.
And if still facing issue than brief your problem here in details.
Had an SSLPoke.bat (SSL troubleshooting script) window script that was getting this error despite importing the correct certificates into the cacerts trustore.
C:\Java\jdk1.8.0_111\jre\lib\security>SSLPoke.bat
C:\Java\jdk1.8.0_111\jre\lib\security>"C:\jdk1.8.0_101\jre\bin\java"
`SSLPoke tfs.corp.****.com 443`
java.net.SocketException: Software caused connection abort: recv failed
`at java.net.SocketInputStream.socketRead0(Native Method)`
`at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)`
`at java.net.SocketInputStream.read(SocketInputStream.java:170)`
`at java.net.SocketInputStream.read(SocketInputStream.java:141)`
`at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)`
`at sun.security.ssl.InputRecord.read(InputRecord.java:503)`
`at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)`
`at sun.security.ssl.SSLSocketImpl.performInitialHandshake
(SSLSocketImpl.java:1375)`
`at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)`
`at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)`
`at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)`
`at SSLPoke.main(SSLPoke.java:28)`
I then checked some old notes about some network changes at my job. We would
need in some cases to add the JVM parameter
-Djava.net.preferIPv4Stack=true to make connections to certain machines
in our network to avoid this error.
C:\Java\jdk1.8.0_111\jre\lib\security>"C:\Java\jdk1.8.0_111\bin\java"
**-Djava.net.preferIPv4Stack=true** SSLPoke tfs.corp.****.com 443
Successfully connected
The code for SSLPoke can be downloaded from here:
https://gist.github.com/4ndrej/4547029
This error happened to me while testing my soap service with SoapUI client, basically I was trying to get a very big message (>500kb) and SoapUI closed the connection by timeout.
On SoapUI go to:
File-->Preferences--Socket Timeout(ms)
...and put a large value, such as 180000 (3 minutes), this won't be the perfect fix for your issue because the file is in fact to large, but at least you will have a response.
Closed connection in another client
In my case, the error was:
java.net.SocketException: Software caused connection abort: recv failed
It was received in eclipse while debugging a java application accessing a H2 database. The source of the error was that I had initially opened the database with SQuirreL to check manually for integrity. I did use the flag to enable multiple connections to the same DB (i.e. AUTO_SERVER=TRUE), so there was no problem connecting to the DB from java.
The error appeared when, after a while --it is a long java process-- I decided to close SQuirreL to free resources. It appears as if SQuirreL were the one "owning" the DB server instance and that it was shut down with the SQuirreL connection.
Restarting the Java application did not yield the error again.
config
Windows 7
Eclipse Kepler
SQuirreL 3.6
org.h2.Driver ver 1.4.192
In the situation explained below, client side will throw such an exception:
The server is asked to authenticate client certificate, but the client provides a certificate which Extended Key Usage doesn't support client auth, so the server doesn't accept the client's certificate, and then it closes the connection.
My server was throwing this exception in the pass 2 days and I solved it by moving the disconnecting function with:
outputStream.close();
inputStream.close();
Client.close();
To the end of the listing thread.
if it will helped anyone.
In my case, I developped the client and the server side, and I have the exception :
Cause : error marshalling arguments; nested exception is:
java.net.SocketException: Software caused connection abort: socket
write error
when classes in client and server are different. I don't download server's classes (Interfaces) on the client, I juste add same files in the project.
But the path must be exactly the same.
For example, on the server project I have java\rmi\services packages with some serviceInterface and implementations, I have to create the same package on the client project. If I change it by java/rmi/server/services for example, I get the above exception.
Same exception if the interface version is different between client and server (even with an empty row added inadvertently ... I think rmi makes a sort of hash of classes to check version ... I don't know...
If it could help ...
I was facing the same problem with wireMock while mocking the rest API calls.
Earlier I was defining the server like this:
WireMockServer wireMockServer = null;
But it should be defined like as shown below:
#Rule
public WireMockRule wireMockRule = new WireMockRule(8089);
I wrote server and client on Java using Netty.When i run client on my PC it works just fine. When i am trying to run client on other PC it throws me:
java.net.ConnectException: connection timed out
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.processConnectTimeout(NioClientSocketPipelineSink.java:391)
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.run(NioClientSocketPipelineSink.java:289)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
17-Sep-2012 10:58:55 AM org.jboss.netty.channel.SimpleChannelHandler
What is the reason of this?
Check the connection parameters.
Is the server visible from another client? (try pinging the server from the client).
Are there any firewalls between? Try switching them off.
Check the connection string. Make sure you aren't connecting to localhost.
Check the server configuration. Does it listen on the proper network interface.
If you check everything and it seems OK. Post the network connection code here.
Happy coding :)
I am using httpclient 4.1.2. If I do a connect to a particular host XYZ and keep
the client program running for more than 5 to 6 hr, connects to the same host XYZ starts giving:
org.apache.http.conn.ConnectTimeoutException: Connect to XYZ timed out
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:377)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
If I connect to a different host, it will succeed. The problem goes away once
I restart my client program. Connecting to the same host through browser will succeed.
Server is a tomcat 6. Both client and server are running on JRE 5. I have set connection timeout = 20000 and socket timeout = 60000. I am using DefaultHttpClient with SingleClientConnManager.
I've seen similar connectivity problems in these cases:
When the programmer does not completely empty the http response object after every request. In particular when you receive an unexpected response code (e.g. 500) - you must still empty the response object.
When there is a firewall/loadbalancer between the client and the server and the request is not being passed to the server. You could look at the number headers you are passing and make sure this is not too high and discard those that are unnecessary.
NOTE: I would consider these timeout values to be extremely high. In general you would expect the server to respond in a couple of seconds rather than tens of seconds.
The wire level logging can be useful in debugging such issues.