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.
Related
Using the AWS IoT Device SDK from GitHub, I'm testing from my local machine using the basic_discovery.py script I can see that it returns the IP address and port from my Raspberry PI running as a Greengrass device, however, I see that I'm getting invalid return codes from the subsequent request when it is attempting to connect with the PI device. The error messages I am getting are as follows:
Trying core arn:aws:iot:us-east-1:111111111111:thing/GreengrassPI at host 192.168.1.176 port 8883
[ERROR] [2022-07-20T20:42:02Z] [00007000017de000] [mqtt-client] - id=0x7fd8b24b4b60: invalid connect return code 4, disconnecting
[ERROR] [2022-07-20T20:42:02Z] [00007000017de000] [tls-handler] - id=0x7fd89242aba0: error reported during SSLRead. OSStatus code -9805
Connection failed with exception AWS_ERROR_MQTT_PROTOCOL_ERROR: Protocol error occurred.
All connection attempts failed
[ERROR] [2022-07-20T20:42:02Z] [0000000116728e00] [mqtt-client] - id=0x7fd8b24b4b60: Connection is not open, and may not be closed
Any suggestions as to what to check? I did not see anything on this in the troubleshooting guide.
[SOLVED] So what I found was that the device name I was using in the test script was not listed in the client device associations for the Greengrass core device. Adding the association resolved the problem. For anyone else that runs into something similar refer to this for information on associating devices. In summary what happened is that the script was able to look up the Greengrass core device but when it attempted to send an MQTT message to it, the Greengrass core device refused it because the device was not associated to it.
We've tryed to test connection to the remote queue manager after installing MQ client v7.5 on Windows Server 2019. We've used Rfhutilc for this and got 'Host not available' inspite of the fact that telnet connection to the corresponding address was succecfully established. Also we tryed to connect using MQ client v9.0 with the same result.
AMQERR01.LOG (client v.7.5) reported following details:
29.09.2020 15:36:10 - Process(10828.2) User(Администратор) Program(rfhutilc.exe)
Host(-) Installation(Installation1)
VRMF(7.5.0.6)
AMQ9208: Error on receive from host 'X.X.X.X'.
EXPLANATION: An error occurred receiving data from 'X.X.X.X' over TCP/IP. This may be due to a communications failure.
ACTION: The return code from the TCP/IP recv() call was 10054 (X'2746'). Record these values and tell the systems administrator.
----- amqccita.c : 4065 -------------------------------------------------------
29.09.2020 15:37:56 - Process(10828.1) User(Администратор) Program(rfhutilc.exe)
Host(-) Installation(Installation1)
VRMF(7.5.0.6)
AMQ9202: Remote host 'X.X.X.X' not available, retry later.
EXPLANATION: The attempt to allocate a conversation using TCP/IP to host 'X.X.X.X' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
ACTION: Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code from TCP/IP is 10060 (X'274C'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host 'X.X.X.X' was not running. If this is the case, perform the relevant operations to start the TCP/IP listening program, and try again.
Here is an example of how traffic data looks like when Rfhutilc refuses to connect to the queue.
As soon as according to the picture there was some code page issue we've tryed to set MQCCSID environment variable with the value 1208 and it helpled.
Also connection attempt via Rfhutilc was succeful while running under another user with login "admin" even though without setting MQCCSID variable.
But I failed to find explanation for this. Did the CCSID of the MQ client differ from system code page of what? And how could I find out default CCSID of MQ client then?
MQ client v7.5 worked just fine on the Windows Server 2012 R2 right after installing. Rfhutilc v7.5 was used both on Server 2012 and Server 2019 for testing.
I have trouble in configuring High Availability, I searched a lot but I was unsuccessful in fixing it.
I got this error : "An error occurred while receiving data: '10054(An existing connection was forcibly closed by the remote host.)'."
I have 3 nodes in implementing AlwaysOn , One of them is Domain Controller and the others have implemented as Failover Clustering.
I configured firewall and windows authentication permission for all nodes but I have gotten the error yet.
Does anybody have any solution?
I found it.
my problem was installed same instance name.
we have a dot net application and it connecting to Oracle and fetching data and moving to SQL server. it was working very fine. just started giving error ORA-12560: TNS:protocol adapter error . Tnsping also giving this error. but if i stop this application and tnsping then its success. again starting the application on the first 10 minutes its working perfectly and gain giving same error. every 5 seconds this application connecting to Oracle databse.
any idea what is this error; and how to resolve. there is lots of questions over here,but didnt find a soulution .
highly appreciate your comments against this query
It seems you have some sort of resource leak. Do you close connections properly ?
Also, as ar said in comment, why don't you just keep this connection open ? IIRC Establishing conn is costly operation in any DBMS.
Also, from documentation:
ORA-12560 -- TNS:protocol adapter error
Cause: A generic protocol adapter error occurred.
Action: Check addresses used for proper protocol specification. Before reporting this error, look at the error stack and check for lower level transport errors. For further details, turn on tracing and reexecute the operation. Turn off tracing when the operation is complete.
UPDATE:
Problem could be caused by overflow of Windows event journal. Check Oracle's events here:
Start menu => Control Panel => Administrative Tools => Event Viewer
You should either clear journal manually or increase its' size
I am working in an environment where we get production issues from time to time related to Oracle connections. We use ODP.NET from ASP.NET applications, and we suspect the firewall closes connections that have been in the connection pool too long.
Sometimes we get an "ORA-12571: TNS packet writer failure" error, and sometimes we get "ORA-03135: connection lost contact."
I was wondering if someone has run into this and/or has an understanding of the difference between the 2 errors.
Using a mobile phone analogy:
ORA-12571 (Failure) Means call is dropped.
ORA-03135 (Connection Lost) Other party hung up.
My understanding is that 3135 occurs when a connection is lost. This doesn't tell you why the connection was lost, though. It may have been terminated by the server because the server failed to recieve a response to a probe for a certain amount of time, and assumed that the connection was dead. Or (I'm not sure about this) the exact reverse of that: the client failed to recieve a probe response from the server for a certain amount of time, so it assumed the connection was lost. The "certain amount of time" is cotrolled by SQLNET.EXPIRE_TIME=[minutes] in sqlnet.ora.
As for 12571, my (again vague) understanding is that there was a sudden failure to send a packet during communication with the server, and that this is typically caused by some software or hardware interfering with the connection (either by design, or by error). For instance, if you pull out your ethernet cable and then try to execute a query, you'll probably get this. Or if a firewall or anti-malware application decides to block the traffic.