I am getting the following error trying to read from a socket. I'm doing a readInt() on that InputStream, and I am getting this error. Perusing the documentation this suggests that the client part of the connection closed the connection. In this scenario, I am the server.
I have access to the client log files and it is not closing the connection, and in fact its log files suggest I am closing the connection. So does anybody have an idea why this is happening? What else to check for? Does this arise when there are local resources that are perhaps reaching thresholds?
I do note that I have the following line:
socket.setSoTimeout(10000);
just prior to the readInt(). There is a reason for this (long story), but just curious, are there circumstances under which this might lead to the indicated error? I have the server running in my IDE, and I happened to leave my IDE stuck on a breakpoint, and I then noticed the exact same errors begin appearing in my own logs in my IDE.
Anyway, just mentioning it, hopefully not a red herring. :-(
There are several possible causes.
The other end has deliberately reset the connection, in a way which I will not document here. It is rare, and generally incorrect, for application software to do this, but it is not unknown for commercial software.
More commonly, it is caused by writing to a connection that the other end has already closed normally. In other words an application protocol error.
It can also be caused by closing a socket when there is unread data in the socket receive buffer.
In Windows, 'software caused connection abort', which is not the same as 'connection reset', is caused by network problems sending from your end. There's a Microsoft knowledge base article about this.
Connection reset simply means that a TCP RST was received. This happens when your peer receives data that it can't process, and there can be various reasons for that.
The simplest is when you close the socket, and then write more data on the output stream. By closing the socket, you told your peer that you are done talking, and it can forget about your connection. When you send more data on that stream anyway, the peer rejects it with an RST to let you know it isn't listening.
In other cases, an intervening firewall or even the remote host itself might "forget" about your TCP connection. This could happen if you don't send any data for a long time (2 hours is a common time-out), or because the peer was rebooted and lost its information about active connections. Sending data on one of these defunct connections will cause a RST too.
Update in response to additional information:
Take a close look at your handling of the SocketTimeoutException. This exception is raised if the configured timeout is exceeded while blocked on a socket operation. The state of the socket itself is not changed when this exception is thrown, but if your exception handler closes the socket, and then tries to write to it, you'll be in a connection reset condition. setSoTimeout() is meant to give you a clean way to break out of a read() operation that might otherwise block forever, without doing dirty things like closing the socket from another thread.
Whenever I have had odd issues like this, I usually sit down with a tool like WireShark and look at the raw data being passed back and forth. You might be surprised where things are being disconnected, and you are only being notified when you try and read.
You should inspect full trace very carefully,
I've a server socket application and fixed a java.net.SocketException: Connection reset case.
In my case it happens while reading from a clientSocket Socket object which is closed its connection because of some reason. (Network lost,firewall or application crash or intended close)
Actually I was re-establishing connection when I got an error while reading from this Socket object.
Socket clientSocket = ServerSocket.accept();
is = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
int readed = is.read(); // WHERE ERROR STARTS !!!
The interesting thing is for my JAVA Socket if a client connects to my ServerSocket and close its connection without sending anything is.read() is being called repeatedly.It seems because of being in an infinite while loop for reading from this socket you try to read from a closed connection.
If you use something like below for read operation;
while(true)
{
Receive();
}
Then you get a stackTrace something like below on and on
java.net.SocketException: Socket is closed
at java.net.ServerSocket.accept(ServerSocket.java:494)
What I did is just closing ServerSocket and renewing my connection and waiting for further incoming client connections
String Receive() throws Exception
{
try {
int readed = is.read();
....
}catch(Exception e)
{
tryReConnect();
logit(); //etc
}
//...
}
This reestablises my connection for unknown client socket losts
private void tryReConnect()
{
try
{
ServerSocket.close();
//empty my old lost connection and let it get by garbage col. immediately
clientSocket=null;
System.gc();
//Wait a new client Socket connection and address this to my local variable
clientSocket= ServerSocket.accept(); // Waiting for another Connection
System.out.println("Connection established...");
}catch (Exception e) {
String message="ReConnect not successful "+e.getMessage();
logit();//etc...
}
}
I couldn't find another way because as you see from below image you can't understand whether connection is lost or not without a try and catch ,because everything seems right . I got this snapshot while I was getting Connection reset continuously.
Embarrassing to say it, but when I had this problem, it was simply a mistake that I was closing the connection before I read all the data. In cases with small strings being returned, it worked, but that was probably due to the whole response was buffered, before I closed it.
In cases of longer amounts of text being returned, the exception was thrown, since more then a buffer was coming back.
You might check for this oversight. Remember opening a URL is like a file, be sure to close it (release the connection) once it has been fully read.
I had the same error. I found the solution for problem now. The problem was client program was finishing before server read the streams.
I had this problem with a SOA system written in Java. I was running both the client and the server on different physical machines and they worked fine for a long time, then those nasty connection resets appeared in the client log and there wasn't anything strange in the server log. Restarting both client and server didn't solve the problem. Finally we discovered that the heap on the server side was rather full so we increased the memory available to the JVM: problem solved! Note that there was no OutOfMemoryError in the log: memory was just scarce, not exhausted.
Check your server's Java version. Happened to me because my Weblogic 10.3.6 was on JDK 1.7.0_75 which was on TLSv1. The rest endpoint I was trying to consume was shutting down anything below TLSv1.2.
By default Weblogic was trying to negotiate the strongest shared protocol. See details here: Issues with setting https.protocols System Property for HTTPS connections.
I added verbose SSL logging to identify the supported TLS. This indicated TLSv1 was being used for the handshake.
-Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack
I resolved this by pushing the feature out to our JDK8-compatible product, JDK8 defaults to TLSv1.2. For those restricted to JDK7, I also successfully tested a workaround for Java 7 by upgrading to TLSv1.2. I used this answer: How to enable TLS 1.2 in Java 7
I also had this problem with a Java program trying to send a command on a server via SSH. The problem was with the machine executing the Java code. It didn't have the permission to connect to the remote server. The write() method was doing alright, but the read() method was throwing a java.net.SocketException: Connection reset. I fixed this problem with adding the client SSH key to the remote server known keys.
In my case was DNS problem .
I put in host file the resolved IP and everything works fine.
Of course it is not a permanent solution put this give me time to fix the DNS problem.
In my experience, I often encounter the following situations;
If you work in a corporate company, contact the network and security team. Because in requests made to external services, it may be necessary to give permission for the relevant endpoint.
Another issue is that the SSL certificate may have expired on the server where your application is running.
I've seen this problem. In my case, there was an error caused by reusing the same ClientRequest object in an specific Java class. That project was using Jboss Resteasy.
Initially only one method was using/invoking the object ClientRequest (placed as global variable in the class) to do a request in an specific URL.
After that, another method was created to get data with another URL, reusing the same ClientRequest object, though.
The solution: in the same class was created another ClientRequest object and exclusively to not be reused.
In my case it was problem with TSL version. I was using Retrofit with OkHttp client and after update ALB on server side I should have to delete my config with connectionSpecs:
OkHttpClient.Builder clientBuilder = new OkHttpClient.Builder();
List<ConnectionSpec> connectionSpecs = new ArrayList<>();
connectionSpecs.add(ConnectionSpec.COMPATIBLE_TLS);
// clientBuilder.connectionSpecs(connectionSpecs);
So try to remove or add this config to use different TSL configurations.
I used to get the 'NotifyUtil::java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:...' message in the Apache Console of my Netbeans7.4 setup.
I tried many solutions to get away from it, what worked for me is enabling the TLS on Tomcat.
Here is how to:
Create a keystore file to store the server's private key and
self-signed certificate by executing the following command:
Windows:
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA
Unix:
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
and specify a password value of "changeit".
As per https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
(This will create a .keystore file in your localuser dir)
Then edit server.xml (uncomment and edit relevant lines) file (%CATALINA_HOME%apache-tomcat-7.0.41.0_base\conf\server.xml) to enable SSL and TLS protocol:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystorePass="changeit" />
I hope this helps
I am using jersey-client (1.9) for calling api and everytime when i need to call a webservice i create a new client instance :
Client client = Client.create();
WebResource webResource = client.resource(url);
ClientResponse response = webResource
.queryParam(PARAM1, param1)
.queryParam(PARAM2, param2)
.type(MediaType.APPLICATION_JSON)
.get(ClientResponse.class);
the problem is after a period of time i get this exception :
com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: No buffer space available (maximum connections reached?): connect
If anyone could help me figure it out I would be very grateful .
You have a resource leak. (Connections and InputStreams backing ClientResponses aren't being closed.) You can read a ClientResponse entity so that its associated resources are automatically closed by calling ClientResponse.readEntity(), or you can manually close them via ClientResponse.close().
The following documentation may not exactly apply to the version of Jersey that you're using, but it's insightful:
Jersey Client API, Closing connections
If you will provide additional details about the OS (windows/linux), more of the code or the type load your service is experiencing - all would help to provide a better answer.
A good guess though is that your OS is running out of sockets ports. Different OS's have different defaults and different ways of configuring how many sockets are available to establish TCP sockets.
though not exactly the same question, this one is similar can shed some light on your situation: java.net.SocketException: No buffer space available (maximum connections reached?): connect
There is also a write up about the same exception here:
http://dbaktiar-on-java.blogspot.com/2010/03/hudson-shows-buffer-space-available.html
I have a simple RabbitMQ example starts as follows :
private Channel channel;
private ConnectionFactory connectionFactory;
#Autowired
public RabbitMqManager() {
connectionFactory = new ConnectionFactory();
connectionFactory.setHost("localhost");
//connectionFactory.setPort(15672); // ERROR : this breaks rabbitmq connection
try {
Connection connection = connectionFactory.newConnection();
channel = connection.createChannel();
If I add setPort then it sometimes causes TimeoutException, sometimes ConnectionRefused. I spent half a day to understand what was happening. Then I've commented out the setPort, everything works.
Note : I can see WebUI (http://localhost:15672) without any problem and server is up & running.
Why setPort breaks the connection initialization? Does RabbitMQ search all the ports to check available server? or does it use the default port 15672 ?
The default port is 5672, not 15672. This is why it works when you comment the line, it's setting the correct port as it's taking the default one. You can check this by calling setPort(5672) (although this is not necessary to set the port, but it will show that the issue is the port number and not the fact you're calling this function).
I am struggling with what seems to be a trivial problem, but I cannot get my head around it. So here it is.
I am working on a project that involves a bunch of microservices deployed on Openshift. Each microservice is built with Spring-Boot 2.1.4. We deploy the .war in a docker Tomcat 9 container. I have no access to the configuration of these containers.
As of now, we removed all the spring-security dependencies to debug the problem more easily.
In one of the microservices, we need to retrieve data from a 3rd party source via a GET method. So we use a RestTemplate.
We implemented a GET method towards a test endpoint (http) to the 3rd party service. It works flawlessly.
Now we have been given a pre-prod endpoint which uses SSL, so we had to convert our GET implementation for the use of SSL.
We have been given a certificate ".crt".
Here are the tests I carried out, that I hope can shed some light.
From the terminal of the Openshift POD, I was able to make successful curl GET calls towards the target https endpoint, in particular:
using the provided certificate renamed in ".pem" (It was likely a pem certificate already, it is clearly readable in notepad) with the --cacert option;
using the insecure option --insecure/-k without the certificate
while it does not work if I remove both the insecure option and the certificate (it complains about "Peer's certificate issuer has been marked as not trusted by the user").
From this information I guessed that the certificate is used to validate the server and not for authentication (I may be totally wrong, mind you. This is the first time I am dealing with this subjects...). So I created a "trustStore.jks" with the Java keytool by importing the certificate ".crt".
I imported the truststore in my spring boot project and configured the RestTemplate to use it, by using one of the guides that you can easily find online, they seem to be all pretty similar [I used this one: https://www.baeldung.com/spring-boot-https-self-signed-certificate].
The result is something like this:
.....
File trustfile = new File(
WebServiceUtils.class
.getClassLoader().getResource("truststore.jks").getFile()
);
UriComponentsBuilder builder = UriComponentsBuilder.fromHttpUrl(endpoint);
String trustStorePath = trustfile.getAbsolutePath();
SSLContext sslContext = new SSLContextBuilder()
.loadTrustMaterial(ResourceUtils.getFile(trustStorePath),
"mypassword".toCharArray())
.build();
SSLConnectionSocketFactory socketFactory = new SSLConnectionSocketFactory(sslContext);
HttpClient client = HttpClients.custom()
.setSSLSocketFactory(socketFactory)
.build();
HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory(client);
RestTemplate restTemplate = new RestTemplate(requestFactory);
HttpEntity entity = new HttpEntity(httpHeaders);
ResponseEntity<T> respEntity = restTemplate.exchange(builder.toUriString(),
HttpMethod.GET,
entity,
in);
return respEntity.getBody();
The problem is that I keep getting a connect timeout and I cannot understand how to solve this problem.
The error is:
org.springframework.web.client.ResourceAccessException: I/O error on GET request for "myHttpsEndpoint": Connect to myHttpsEndpoint failed: Connection timed out (Connection timed out); nested exception is org.apache.http.conn.HttpHostConnectException: Connect to myHttpsEndpoint failed: Connection timed out (Connection timed out)
Now, I am sure the keystore gets at least read correctly since, if I purposely insert a wrong password, it warns me.
I tried many tweaks that I found here on StackOverflow without success.
What puzzles me the most is that despite all my tests, the error never changes. It gets stuck always there.
This lead me to believe that I may be blocked by something else, a firewall of some kind. I am guessing, I may be wrong obviously.
And even if that was the case, I cannot even explain why from curl, in the pod terminal, it works.
It also works if I use the GET method without SSL with the pre-prod https endpoint (the GET method that I was using against the test endpoint, the one written for the http endpoint).
I would like to have an expert opinion from you.
Can it be a configuration-related error not in my control?
Thank you very much!
I'm using Graphite.NET for logging to statsD. Underneath the hood, it uses UdpClient to write to the statD server. Source. I think makes sense to create this as a singleton because I will be logging frequently and it seems that there will be a lot of overhead in creating this client and connecting every time I want to log. Is there any downside to doing this? What happens if the connection gets interrupted: will an exception be thrown? Will my logger be recreated by StuctureMap next time I try to use the logger? Here's what my SM configuration looks like:
x.For<IStatsDClientAdapter>()
.Singleton()
.Use<StatsDClientAdapter>()
.Ctor<string>("hostname").EqualToAppSetting("GraphiteHostname")
.Ctor<int>("port").EqualToAppSetting("GraphitePort")
.Ctor<string>("keyPrefix").EqualToAppSetting("GraphiteKeyPrefix");
Because the Graphite.NET StatsDClient instantiates and calls Connect on UdpClient in it's constructor, your ability to recover from initial connection exceptions are limited if you only make this call once (e.g. at application startup via depencency injected singleton - as you've done).
Using a Singleton with this StatsDClient means you'd need to catch and re-instantiate the StatsDClient if a connection issue occurred in order to insure that your application was initialized correctly (i.e. with a working StatsDClient)... because, again, Connect is run in the constructor.
That said, if the StatsDClient initializes successfully (i.e. Connect doesn't throw an exception) then you should be OK even if the server goes down afterward because UDP is connectionless and StatsDClient is handling/catching any exception that occurs on Send(). The client should just keep right on firing Sends at the Ip and Port that was established in the default connection with no knowledge of whether the server is good/bad.
Too bad the Graphite.NET StatsDClient doesn't pass the ip and port to UdpClient.Send() - http://msdn.microsoft.com/en-us/library/acf44a1a.aspx) instead of using a default connection via the constructor... as this would make using a static member possible (as you'd be able to construct usable StatsDClients under any conditions).
Long story short, in order to avoid getting your application into a bad state, I'd instantiate at usage time. As follows:
using(var statsdclient = new StatsDClient("my.statsd.host", 8125, "whatever.blah"))
{
statsdclient.Increment("asdf");
}
Or, alternatively, fork StatsDClient and modify it to pass the IP and Port on the Send().