Another ManagedDataAccess NullReferenceException bug like issue 164
burnchar opened this issue · 4 comments
We are seeing a Oracle.ManagedDataAccess.Core bug which seems nearly identical to Issue 164
System.AggregateException: One or more errors occurred. (Object reference not set to an instance of an object.)| ---> System.NullReferenceException: Object reference not set to an instance of an object. at OracleInternal.ConnectionPool.PoolManager
3.CreateNewPRAsync(Int32 reqCount, Boolean bForPoolPopulation, ConnectionString csWithDiffOrNewPassw, OracleConnection connRefForCriteria, Boolean bIncrSemObtained, Boolean bMaxSemObtained, Boolean bIgnoreIdleSem, PMCNPR_RefAndOutParamArgCtx pmcnpr_refOutctx, String instanceName, List1 switchFailedInstNames, Boolean bAsync) at OracleInternal.ConnectionPool.OraclePoolManager.CreateNewPRAsync(Int32 reqCount, Boolean bForPoolPopulation, ConnectionString csWithDiffOrNewPassw, OracleConnection connRefForCriteria, Boolean bIncrSemObtained, Boolean bMaxSemObtained, Boolean bIgnoreIdleSem, PMCNPR_RefAndOutParamArgCtx pmcnpr_refOutctx, String instanceName, List
1 switchFailedInstNames, Boolean bAsync)
at OracleInternal.ConnectionPool.PoolManager3.GetAsync(ConnectionString csWithDiffOrNewPassw, Boolean bGetForApp, OracleConnection connRefForCriteria, String affinityInstanceName, Boolean bForceMatch, Boolean bAsync) at OracleInternal.ConnectionPool.OraclePoolManager.GetAsync(ConnectionString csWithNewPassw, Boolean bGetForApp, OracleConnection connRefForCriteria, String affinityInstanceName, Boolean bForceMatch, Boolean bAsync) at OracleInternal.ConnectionPool.OracleConnectionDispenser
3.GetAsync(ConnectionString cs, PM conPM, ConnectionString pmCS, OracleOpaqueString securedPassw, OracleOpaqueString securedProxyPassw, OracleConnection connRefForCriteria, Boolean bAsync)
at Oracle.ManagedDataAccess.Client.OracleConnectionInternal.OpenInternalAsync(Boolean bAsync)
at Oracle.ManagedDataAccess.Client.OracleConnectionInternal.OpenAsyncHelper(CancellationToken cancellationToken)
at Oracle.ManagedDataAccess.Client.OracleConnectionInternal.OpenAsync(CancellationToken cancellationToken)
at Dapper.SqlMapper.QueryAsync[T](IDbConnection cnn, Type effectiveType, CommandDefinition command) in /_/Dapper/SqlMapper.Async.cs:line 433
at FastCoreLib.Database.ExtensionMethods.DapperResilientExtensions.<>c__DisplayClass4_01.<<QueryResilientAsync>b__0>d.MoveNext()| --- End of stack trace from previous location ---|
For connection string:
Data Source=(DESCRIPTION_LIST=(FAILOVER=TRUE)(LOAD_BALANCE=OFF)(DESCRIPTION=(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS=(PROTOCOL=TCP)(HOST=prodh1wsd-scan.mycompany.net)(PORT=1535))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=srv_smartprod)))(DESCRIPTION=(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS=(PROTOCOL=TCP)(HOST=prodh2wsd-scan.mycompany.net)(PORT=1535))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=srv_smartprod))));User ID=<redacted>;Password=<redacted>
Does anyone have an idea of how can we work around this bug while it gets fixed?
Which ODP.NET version are you using? There was a bug fixed (36879313) in ODP.NET Core 23.6 related to DESCRIPTION_LIST in that release.
Does the connection work if you just use the DESCRIPTION part of the connect descriptor without the DESCRIPTION_LIST? The problem source may be recognizing DESCRIPTION_LIST.
#164 dealt with ADDRESS_LIST.
Alex, I appreciate the response. I was ready to say that we are using the latest, but this particular application is using 23.5.1. I will update it to 23.6.0, and separately test without DESCRIPTION_LIST.
@burnchar I tried using a similar connect descriptor with a DESCRIPTION_LIST and two DESCRIPTIONs and OpenAsync()
. I was able to connect successfully.
Can you upload a trace to this thread or email us your trace, dotnet_us(at)oracle.com? The trace will have more diagnostic info about the object reference error.
You can turn on tracing by adding the following two lines to your code before you open a connection.
OracleConfiguration.TraceFileLocation = @"C:\traces";
OracleConfiguration.TraceLevel = 7;
The Oracle.ManagedDataAccess upgrade from 23.5.1 to 23.6.0 appears to have resolved the issue. We would have seen the same error reliabily within a few hours, and it has been several days. My thanks for your assistance.