The channel adapter is for one way communication.
But while using TcpSendingMessageHandler, the adapter is expecting a reply. and the following message is thrown same is the case with TcpOutboundGateway.
TcpNetConnection : Read Exception [Connection ID] Socket Exception : software caused connection abort: recv failed
Please help me to overcome this issue.
The sending adapter is not expecting a reply; it is possible, however, that the application has collaborating channel adapters (a receiving adapter that uses the same connection).
Even if there is no listener, we have to read from the socket so we can log that an unexpected reply was received. If we don't read from the socket, the peer could end up blocking when the buffers fill up.
What problem is this causing you?
This is typically only logged at DEBUG or TRACE level.
Related
we are getting ORA-12570: Network Session: Unexpected packet read error from our webapi written in .Net core 2.2. The API is hosted in Alpine Docker OS 3.11 in GCP using kubernetes. We are using Oracle.ManagedDataAccess.Core version 2.19.60.
The intrenal error message we get is
Oracle.ManagedDataAccess.Client.OracleException (0x80004005): ORA-12570: Network Session: Unexpected packet read error ---> OracleInternal.Network.NetworkException (0x80004005): ORA-12570: Network Session: Unexpected packet read error ---> System.Net.Sockets.SocketException (110): Operation timed out.
Per the website http://www.dba-oracle.com/t_ora_12570_tns_packet_reader_failure.htm, ORA-12570 occur due to listener configuration. IS that true? Also Let us know how if tracing works in linux for ODP.Net core.
Thanks
This is a generic error; it is not necessarily related to the Oracle Listener. The key here is "System.Net.Sockets.SocketException (110): Operation timed out." This could be a lot of things; you really need to do Oracle Net tracing to determine what's going on. Could be that your client can't see the network at all, or that network latency or packet routing are not what they should be, or several other things.
I am getting socket exception for broken pipe in my client side.
[write] I/O error: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Broken pipe (Write failed)
[LoggingManagedHttpClientConnection::shutdown] http-outgoing-278: Shutdown connection
1520546494584[20180308 23:01:34] [ConnectionHolder::abortConnection] Connection discarded
1520546494584[20180308 23:01:34] [BasicHttpClientConnectionManager::releaseConnection] Releasing connection [Not bound]
It seems that the upgradation of httpclient jar is causing issue.
Issue is not coming with httpclient-4.3.2
Exception is coming in every 2 minutes. Issue is intermittent at times.
after , send expect:100-continue ,conn.flush is throwing exception
client and server are Linux machine
client uses http jar to make request to server REST.
Please help me in debugging the issue
can httpjar cause such issue?
The persistent connections that are kept alive by the connection manager become stale. That is, the target server shuts down the connection on its end without HttpClient being able to react to that event, while the connection is being idle, thus rendering the connection half-closed or 'stale'
This is a general limitation of the blocking I/O in Java. There is simply no way of finding out whether or not the opposite endpoint has closed connection other than by attempting to read from the socket.
If a stale connection is used to transmit a request message the request execution usually fails in the write operation with SocketException and gets automatically retried.
Apache HttpClient works this problem around by employing the so stale connection check which is essentially a very brief read operation. However, the check can and often is disabled. In fact it is often advisable to have it disabled due to extra latency the check introduces.
The handling of stale connections was changed in version 4.4. Previously, the code would check every connection by default before re-using it. The code now only checks the connection if the elapsed time since the last use of the connection exceeds the timeout that has been set. The default timeout is set to 2000ms
I have an application that is listening for data received from GPRS units in the field on a normal TCP connection. I'm getting Winsock 10054 and 10053 errors.
As explained by microsoft
10053 : Software caused connection abort. An established connection was aborted by the software in your host machine, possibly due to a data transmission time-out or protocol error.
and
10054 : Connection reset by peer. An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, or the remote host uses a hard close (see setsockopt (Windows Sockets) for more information on the SO_LINGER option on the remote socket.) This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
I'm not sure how to interpret this. How do I determine if the error is caused on the server or by the client sending the information?
I am using boost::asio::tcp::socket to connect to a Server, and call
read_some() to receive binary data from Server, the following are codes:
len = sock->read_some(boost::asio::buffer(pBuf), error);
if (error == boost::asio::error::eof) {
break;
}
else if (error) {
break;
}
But after the Server closed the socket, the client still blocked in read_some method, fail to detect disconnection with server and get the error message. Why this problem occurs?
It's either because you failed to correctly implement the protocol you are using on top of TCP or because of a design flaw in that protocol. If the protocol says to wait forever for data from the server without sending anything, then the fault is in the protocol. If the protocol says to timeout the read or to send some data and you're not doing that, then the flaw is in your implementation of the protocol.
TCP does not guarantee that a connection loss can be detected by a side that is not trying to send any data. Protocols that use TCP must be designed around this.
What is the error returned on aix/linux when a connection breaks down due to keepalive activity? Is it a unique error code which can be distinguished from other socket errors?
On windows this can be either WSAECONNRESET or WSAENETRESET.
Is there a way to differentiate the error due to keepalive activity when WSAECONNRESET is returned?
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
Is there a way to differentiate the error due to keepalive activity when WSAECONNRESET is returned ?
No. The underlying condition is a 'connection reset' in all cases.