Using jedis client to save data to redis localhost.
Once I connect to redisHost using jedis, I am not disconnecting as long as I get messages Is that an issue? Tried to change the timeout from default 2000 to 6000 but still the same error!
connecting and sending data:
if (jedis == null)
jedis = new Jedis(redisHost);
if (!jedis.isConnected())
jedis.connect();
if (jedis.isConnected())
jedis.zadd("someKey", doubleTime, "someValue");
following is the stack trace of the error receiving:
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketException: Software caused connection abort: socket write error
at redis.clients.jedis.Protocol.sendCommand(Protocol.java:92)
at redis.clients.jedis.Protocol.sendCommand(Protocol.java:72)
at redis.clients.jedis.Connection.sendCommand(Connection.java:80)
at redis.clients.jedis.BinaryClient.zadd(BinaryClient.java:387)
at redis.clients.jedis.Client.zadd(Client.java:327)
at redis.clients.jedis.Jedis.zadd(Jedis.java:1468)
at com.comcast.xre.WebSocketServer.saveLogToDB(WebSocketServer.java:105)
at com.comcast.xre.WebSocketServer.access$000(WebSocketServer.java:27)
at com.comcast.xre.WebSocketServer$1$1.onFullTextMessage(WebSocketServer.java:69)
at io.undertow.websockets.core.AbstractReceiveListener$2.complete(AbstractReceiveListener.java:138)
at io.undertow.websockets.core.AbstractReceiveListener$2.complete(AbstractReceiveListener.java:134)
at io.undertow.websockets.core.BufferedTextMessage.read(BufferedTextMessage.java:87)
at io.undertow.websockets.core.AbstractReceiveListener.readBufferedText(AbstractReceiveListener.java:134)
at io.undertow.websockets.core.AbstractReceiveListener.bufferFullMessage(AbstractReceiveListener.java:72)
at io.undertow.websockets.core.AbstractReceiveListener.onText(AbstractReceiveListener.java:52)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:26)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
Caused by: java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at redis.clients.util.RedisOutputStream.flushBuffer(RedisOutputStream.java:31)
at redis.clients.util.RedisOutputStream.write(RedisOutputStream.java:38)
at redis.clients.jedis.Protocol.sendCommand(Protocol.java:78)
... 23 more
Issue was with Jedis connection. It's connected but after few messages, connection is broken.
After each save to DB, I am disconnecting and removing the jedis client completely and creating a new client and connection. Looks awkward but it solves the issue.
Related
I saw a lot of "java.net.ConnectException: Connection refused" questions but none referring to timeout of this error. My problem is I have to connect to a server that, in some cases, is blocked (connected by another software to the same port). So, I'm doing a loop with some max retries to try to connect:
My current code (of course, is depending on a lot of configurations for my software, but is working fine):
public TCPConnector(TCPDefinition tcpDefinition) throws IAException {
ivTcpDefinition = tcpDefinition;
// Initialize the socket
boolean retry = false;
int counter = 1;
do {
try {
ivSocket = new Socket();
ivSocket.connect(new InetSocketAddress(tcpDefinition.getHostname(), tcpDefinition.getPort()), tcpDefinition.getConnectTimeOut());
ivSocket.setSoTimeout(tcpDefinition.getAckTimeOut());
retry = false;
}
catch (UnknownHostException uhe) {
throw new IAException(null, new StringBuffer("Can't find host: ").append(tcpDefinition.getHostname()).toString(), uhe);
}
catch (SocketException see) {
StringBuilder sb = new StringBuilder("Connection refused to host ").append(tcpDefinition.getHostname()).
append(" port ").append(tcpDefinition.getPort()).append(". Connection Attempt Nr. ").append(counter);
logger.error(sb.toString(), see);
retry = true;
if (counter++ > tcpDefinition.getConnectRetries())
throw new IAException(null, sb.toString(), see);
else
logger.error("will retry to connect");
}
catch (IOException ioe) {
StringBuilder sb = new StringBuilder("I/O error while connecting to host ").append(tcpDefinition.getHostname()).
append(" port ").append(tcpDefinition.getPort()).append(". Connection Attempt Nr. ").append(counter);
logger.error(sb.toString(), ioe);
retry = true;
if (counter++ > tcpDefinition.getConnectRetries())
throw new IAException(null, sb.toString(), ioe);
else
logger.error("will retry to connect");
}
}
while (retry);
}
Well, the problem is this:
On Windows, every second, the SocketException is thrown, instead the IOException, while I have configured a timeout of 5000 msec to ivSocket.connect
On Linux, this is thrown every millisecond!!
Windows:
2019-12-05 12:40:47,609 ERROR DefaultQuartzScheduler_Worker-1 TCPConnector - Connection refused to host localhost port 13002. Connection Attempt Nr. 1
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
2019-12-05 12:40:48,703 ERROR DefaultQuartzScheduler_Worker-1 TCPConnector - Connection refused to host localhost port 13002. Connection Attempt Nr. 2
java.net.ConnectException: Connection refused: connect
Linux:
2019-12-05 12:45:47,609 ERROR DefaultQuartzScheduler_Worker-1 TCPConnector - Connection refused to host localhost port 13002. Connection Attempt Nr. 1
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
2019-12-05 12:45:47,610 ERROR DefaultQuartzScheduler_Worker-1 TCPConnector - Connection refused to host localhost port 13002. Connection Attempt Nr. 2
java.net.ConnectException: Connection refused: connect
Why the timeout is not executed? Well this is not exactly right. If I configure a timeout less than 1 second on Windows, then the timeout is executed. 500 msec:
2019-12-05 11:47:07,375 ERROR DefaultQuartzScheduler_Worker-1 TCPConnector - I/O error while connecting to host localhost port 13002. Connection Attempt Nr. 1
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
2019-12-05 11:47:07,875 ERROR DefaultQuartzScheduler_Worker-1 TCPConnector - I/O error while connecting to host localhost port 13002. Connection Attempt Nr. 2
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
It is possible to configure a "connect refuse" timeout?
There is no such thing as a "connection refused timeout".
"Connection refused" happens when the server sees the connection request, but there is no service listening for connections on the IP + port that the request is directed to. The server then "refuses" the connection. This typically happens instantly, so so no timeout is triggered.
"Connection timed out" happens (typically) when something stops the connection request from reaching the server1, 2. So the client-side will wait for the response from the server, and then resend / wait a few times. And eventually the time allotted for establishing a connection will expire ... and the connection times out.
As you can see these are different scenarios. And they are reported back to the Java client-side differently.
So the reason you are not getting timeouts is that the "connection refused" responses are coming back quick enough that your configured timeout is not exceeded.
That might also explain why setting the connect timeout small might have changed the behavior. There may also be issues with the granularity of the timeout that the OS allows Java to set.
To investigate this further, I think we would need a minimal reproducible example. For example, we need to see how you have implemented the code that manages the server-socket and accepts connections on the server side.
1 - The blockage could be on the server's reply packets.
2 - There are various possible causes for this kind of thing. The most likely are a firewall blocking traffic somewhere, a network routing problem, or using a private IP address on the wrong network.
I have a weak connection with database server and time consuming query which is sometimes fails with exception:
Caused by: java.sql.SQLException: I/O Error: Socket closed
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2481)
at net.sourceforge.jtds.jdbc.TdsCore.getNextRow(TdsCore.java:805)
at net.sourceforge.jtds.jdbc.JtdsResultSet.next(JtdsResultSet.java:611)
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.io.DataInputStream.readFully(DataInputStream.java:195)
at net.sourceforge.jtds.jdbc.SharedSocket.readPacket(SharedSocket.java:885)
at net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:731)
at net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:477)
at net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:146)
at net.sourceforge.jtds.jdbc.TdsData.readData(TdsData.java:901)
at net.sourceforge.jtds.jdbc.TdsCore.tdsRowToken(TdsCore.java:3175)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2433)
How can connection interruption be handled? currently I have to manually re-run the operation until it executes successfully, maybe it could be done at jdbc driver level
ps socketTimeout property doesn't seem to affect this
Are you sure this is because of query/procedure taking long time ? As Socket closed error normally means something went wrong with the network connection itself, basically something that your driver could not control...
In general, I would suggest to move to a Pool based mechanism, which allows greater control on your persistence layer interaction.
I get the following exception when sending data to solr using the ContentStreamUpdateRequest of SolrJ
Exception in thread "main" org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Software caused connection abort: socket write error
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:478)
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244)
at com.atosworldline.documentarchiver.core.solr.SolrIndexer.addDocument(SolrIndexer.java:48)
at com.atosworldline.documentarchiver.core.solr.SolrIndexerTest.main(SolrIndexerTest.java:14)
Caused by: java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
at org.apache.commons.httpclient.HttpConnection.write(HttpConnection.java:975)
at org.apache.commons.httpclient.HttpConnection.write(HttpConnection.java:943)
at org.apache.commons.httpclient.HttpConnection.print(HttpConnection.java:1033)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.print(MultiThreadedHttpConnectionManager.java:1644)
at org.apache.commons.httpclient.HttpMethodBase.writeRequestLine(HttpMethodBase.java:2218)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2059)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:422)
... 3 more
The reason for that exception is, that I'm sending the binary data of the document to solr. If I remove this, the application runs successfull.
I'm using the following code to send the request
SolrServer solrServer = new CommonsHttpSolrServer(url);
ContentStreamUpdateRequest request = new ContentStreamUpdateRequest(EXTRACT);
request.addFile(document);
//request.setParam("literal.id", documentName);
request.setAction(ACTION.COMMIT, true, true);
byte[] byteContent = FileUtils.readFileToByteArray(document);
String base64encodedFile = Base64.byteArrayToBase64(byteContent, 0, byteContent.length);
request.setParam(SolrDBSchema.DOCUMENT.toString(), base64encodedFile);
request.setParam("literal." + SolrDBSchema.OWNER.toString(), owner);
request.setParam("literal." + SolrDBSchema.VALID.toString(), Boolean.toString(valid));
request.setParam("literal." + SolrDBSchema.DATE.toString(), validFor.toString());
request.setParam("literal." + SolrDBSchema.DOCUMENT_TYPE.toString(), documentType);
solrServer.request(request);
I think the String base64encodedFile is to long for a HTTP request, but I don't know a solution for that problem. As far as I know Solr is not able to store the document by configuration.
Since you are using SolrJ, consider setting the RequestWriter to use the BinaryRequestWriter, like this:
solrServer.setRequestWriter(new BinaryRequestWriter());
This will allow you to write your data to Solr in the binary format and may bypass the issue you are experiencing sending the large data stream as XML.
Note that you will need to ensure you have the BinaryUpdateRequestHandler enabled in your solrconfig.xml settings.
<requestHandler name="/update/javabin" class="solr.BinaryUpdateRequestHandler" />
When I try to use sockets in my Java application, I get a SocketException:
SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:186)
at java.net.SocketInputStream.read(SocketInputStream.java:200)
at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2266)
at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2559)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2569)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at Form.Server.transfer(Server.java:69)
at Form.Server.main(Server.java:53)
java.net.SocketException: Connection reset
This question already has answers here:
java.net.SocketException: Connection reset
(14 answers)
Closed 7 years ago.
I am getting the following error frequently while retrieving file object from database column. How can I resolve this problem?
May 8, 2009 3:18:14 PM org.apache.catalina.core.StandardHostValve status
WARNING: Exception Processing ErrorPage[errorCode=404, location=/error.jsp]
ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:327)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:293)
at org.apache.catalina.connector.Response.flushBuffer(Response.java:537)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:286)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:746)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433)
at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:304)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:991)
at org.apache.coyote.Response.action(Response.java:182)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:322)
... 13 more
Your HTTP client disconnected.
This could have a couple of reasons:
Responding to the request took too long, the client gave up
You responded with something the client did not understand
The end-user actually cancelled the request
A network error occurred
... probably more
You can fairly easily emulate the behavior:
URL url = new URL("http://example.com/path/to/the/file");
int numberOfBytesToRead = 200;
byte[] buffer = new byte[numberOfBytesToRead];
int numberOfBytesRead = url.openStream().read(buffer);
Your log indicates ClientAbortException, which occurs when your HTTP client drops the connection with the server and this happened before server could close the server socket Connection.
I have got this error on open page from Google Cache.
I think, cached page(client) disconnecting on page loading.
You can ignore this error log with try-catch on filter.
Windows Firewall could cause this exception, try to disable it or add a rule for port or even program (java)