Develop Reference

"java.net.SocketException: Software caused connection abort" For no particular reason 30 seconds after socket connection [duplicate]

This question already has answers here:
Official reasons for "Software caused connection abort: socket write error"
(14 answers)
Closed 3 years ago.
I am facing a strange issue with Android's airplane mode and a Socket exception 30 seconds after opening a new Socket connection.
Here's what I do on my app that creates an issue:
Have an opened Socket connection and turn on and off airplane mode.
Reopen a new Socket connection with the server.
Wait 30 seconds and get a java.net.SocketException: Software caused connection abort on a DataInputStream readByte() call.
I have checked my server logs and the server is not disconnecting the client.
Does anyone know what could cause this? I've browsed other posts with the same exception, but they all had a more detailed error message. I can also send and receive messages with that Socket connection fine for 30 seconds, but then it randomly throws an exception.

i think to mange this case , opening airplane mode and turning of you should make listener
for internet connection and when internet state change to there is connection rebuild your socket and when state changed to no internet close the socket
you CAN find an example on Internet connectivity change listener here

xmpp with openfire client connection lost suddently with smack 4.1

I am working with the XMPPTCPConnection to connect with my openfire server, Connected successfully and sent/receive data packets successfully. Connection remains stable but suddenly drops with an exception and I am getting no clue about this exception.
My server disconnect idle user time is 60 sec. And I have implemented all ping manager, and re-connection code. So its reconnecting but not getting why it get disconnected with exception or how to resolve this exception.
E/MainService: Connection to XMPP server was lost.org.jivesoftware.smack.SmackException: Parser got END_DOCUMENT event. This could happen e.g. if the server closed the connection without sending a closing stream element
07-28 10:21:22.003 12719-16068/com.thatsit.android D/SMACK:
XMPPConnection closed due to an exception (0)
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: org.jivesoftware.smack.SmackException: Parser got END_DOCUMENT event. This could happen e.g. if the server closed the connection without sending a closing stream element
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1170)
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:952)
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:967)
07-28 10:21:22.013 12719-16068/com.thatsit.android W/System.err: at java.lang.Thread.run(Thread.java:818)
Any help will be highly appreciate.

there is no need to disconnect ideal users.
If you again disconnect then make a service that is working in background and check the xmpp connection every 10 seconds.If connected then there is no need to connect but if disconnect then connect it to server again. I have handled this from my app.
I have also open source code on github.If you want then you can refer from there.
This is not updated code with 4.1 but i have already made changes but need to upload. Today evening i'll upload updated code.
Thanks, Hope this will help to solve your problem.

Actually there are two issues related to yours: one is in Openfire 4.x.x and one is in the Smack 4.0.7 library.
There is a bug (OF-1308) in Openfire 4.x.x and above that when the server disconnects a client, it doesn't send the end-tag of stream to the client as an intentional disconnection. It just closes the socket and causes PacketReader getting END_DOC event.
In Smack, the PacketReader handles IOException (unexpected loss of network connectivity), end-tag of stream (an intentional disconnection), or END_DOC (unexpected disconnection from server like server crashed.) Getting IOException will trigger Reconnection Manager if it is enabled. Getting an end-tag of stream will trigger normal connection close event. However, Smack treats the END_DOC as getting end-tag of stream. In my opinion, Smack should treat END_DOC as IOException since the end-tag of stream has not been received.
There is another twist. If you have compression enabled, PacketReader gets IOException if the server simply closes the socket. If compression is disabled, PacketReader gets END_DOC if the server simply closes the socket.
In your case, when there is an idle timeout enabled, the client should not trigger ReconnectionManager. Otherwise, it defeats the purpose of idle timeout. I am testing my fix, so I haven't reported the Smack bug to the Ignite Community yet.

Reconnection Error Stream Management Smack

i discovered a really big problem (probably mine?) about the XMPP reconnection process in smack library v4.1.5 (Android) and openfire v4.0.1.
I activated the stream management on the client in this way:
XMPPTCPConnection.setUseStreamManagementDefault(true);
XMPPTCPConnection.setUseStreamManagementResumptionDefault(true);
and activated the automatic reconnection in this way:
ReconnectionManager.getInstanceFor(this.xmppConnection).enableAutomaticReconnection();
After the first successfull connection and login, when the internet connection goes down and the reconnection process starts I get the following error:
W/AbstractXMPPConnection: Connection closed with error
org.jivesoftware.smack.XMPPException$StreamErrorException: conflict You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1003)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:944)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:959)
The reconnection manager connects and authenticates very well but then I receive the previous error!
I tried to change the resource also but nothing, it doesn't work!
Someone could help me in understanding what is wrong?

when connect web service with ksoap2 i took this error java.net.SocketTimeoutException

i'm developing an android project.i used ksoap2 lib.And i'm writing axis2 web service
but i took this error on client(android)
java.net.SocketTimeoutException: failed to connect to /10.0.2.2 (port 8080) after 600000ms: isConnected failed: ETIMEDOUT (Connection timed out)
Thanks..

java.net.SocketTimeoutException is a subclass of java.io.IOException. It signals that a timeout has occurred on a socket read or accept”. That means that this exception emerges when a blocking operation of the two, an accept or a read, is blocked for a certain amount of time, called the timeout. Let’s say that the socket is configured with a timeout of 5 seconds. If either the accept() or read() method, blocks for more than 5 seconds, a SocketTimeoutException is thrown, designating that a timeout has occurred.
To avoid that exception:-
If the server side application is under your control, you should try yo adjust the timeout barrier so that its more flexible on network delays. You should surely consider doing that especially when your server application will run in a remote machine. Other than that, you can check whatever causes delays in your network, a malfunctioning router etc. Another way to effectively handle it is to define a connection timeout and later handle it by using a try catch block....
e.g,
HttpUrlConnection conn = (HttpURLConnection) url.openConnection();
conn.setConnectTimeout(time_in_millisec); //set the required timeout in milliseconds
It is important to note that after this exception is thrown. the socket remains valid, so you can retry the blocking call or do whatever you want with the valid socket (even reconnecting the server from catch block)
For more detail please go through the link http://examples.javacodegeeks.com/core-java/net/sockettimeoutexception/java-net-sockettimeoutexception-how-to-solve-sockettimeoutexception/
Source: www.simpalm.com

Socket close timing

I have what appears to be a timing problem between a client (Galaxy Nexus) and a custom server since upgrading from Ice Cream Sandwich to Jelly Bean. Here is the general flow:
Client opens socket, issues HTTP get to server
Server accepts, starts new thread, responds with HTTP header and 200 OK.
Server writes (binary) file to socket.
Client reads data from socket and saves to a file.
After server thread writes all data, it closes the socket, and terminates
This has worked well over the past several months prior to the Jelly Bean update. Since the update the binary transfer succeeds about 70% of the time. The remaining 30% fails
when 'serverSocket.getInputStream().read' returns a -1 indicating the end of stream has been reached. No data has been read, no error exceptions raised, nothing in logcat.
The possibility of a timing problem arises when I change the server behavior in step #5. The thread was closing the socket after the write with the observed problems. If I remove the socket close, terminate the thread after the write, and let the OS eventually close the socket then it seems to work all the time.
I used tcpdump and WireShark to look at the packets in both the successful and failed cases. In the failed case a socket is closed in a few milli-seconds while in the successful case the socket is closed is a quarter or more of a second. The net of this is that any delay we cause in the socket closing improves our chances for success.
If anyone has any suggestions with what we may be doing to cause this problem or suggestions on how to narrow down the problem please feel free to respond. I can add code samples if required.

It looks like that when the server ask for the connection close, the socket is immediatly closed. Maybe the default ocket linger's time has changed between version ???
Try setting the socket linger's time using:
socket.setSoLinger(boolean on, int timeout);
to have the server waiting some time before close channel if some data still waiting to be sent.
If this doesn't solve, you can change your flow above to:
...
4.Client reads data from socket and saves to a file.
5.Client send confirmation to server.
6.Server close connection.
--EDITED--
A gracefull way to achive the above without additional TCP data packets traveling for the closing confirmation is:
when server finish writing to the socket calls:
socket.shutdownOutput();
when client socket.read() returns -1, client calls:
socket.close();
This ensures that client is informed that all data has been sent, and sender will wait for the socket closure protocol to complete.