java.net.SocketException: Connection reset

I’m using smack to connect to the hipchat server. The xmpp connection throws the following error every few minutes and then reconnects to the server. What’s the cause of this?

xmlns=‘jabber:iq:last’ seconds=‘900’/><client_type>http://hipchat.com/client/mac/macweb</client_type>

Smack Packet Reader (0), handling exception: java.net.SocketException: Connection reset

%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA256]

Smack Packet Reader (0), SEND TLSv1.2 ALERT: fatal, description = unexpected_message

Smack Packet Reader (0), WRITE: TLSv1.2 Alert, length = 64

Smack Packet Reader (0), Exception sending alert: java.net.SocketException: Broken pipe (Write failed)

Smack Packet Reader (0), called closeSocket()

Smack Packet Writer (0), called close()

Smack Packet Writer (0), called closeInternal(true)

Smack Packet Reader (0), called close()

Smack Packet Reader (0), called closeInternal(true)

22-Feb-2017 11:48:41.065 WARNING [Smack Packet Reader (0)] org.jivesoftware.smack.AbstractXMPPConnection.callConnectionClosedOnErrorListen er Connection closed with error

java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:210)

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.readDataRecord(SSLSocketImpl.java:930)

at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)

at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)

at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)

at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)

at java.io.InputStreamReader.read(InputStreamReader.java:184)

at java.io.BufferedReader.fill(BufferedReader.java:161)

at java.io.BufferedReader.read1(BufferedReader.java:212)

at java.io.BufferedReader.read(BufferedReader.java:286)

at org.jivesoftware.smack.util.ObservableReader.read(ObservableReader.java:41)

at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2992)

at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)

at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1144)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:1177)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPCon nection.java:956)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:971)

at java.lang.Thread.run(Thread.java:745)

@George: I am having the same issue. Are you able to resolve this? any help is appreciated. Thanks

I fixed the issue using PingManager.

As stated on this page Setting up XMPP/Jabber clients for HipChat - Atlassian Documentation connections are dropped after 150 seconds of inactivity. Pinging the server every 10 seconds solved the problem for me, although that’s probably overkill. Hope that helps.

There are several possible causes.

The other end has deliberately reset the connection. 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.

Not necessarily, especially since it would then usually say “reset by peer” in the SocketException message. In this case, a local reason is more likely. For example, the local interface, on which the local IP address was bound used in the connection, went down.

Why would you want to close a socket that is already closed in both directions?

I don’t think you need to send data for that. Closing a stale TCP connection would have the same effect. But then again, in this situation, the connection state is way past the point where you could close it anyway.