Closed avrahamcool closed 6 months ago
If you can publish a complete test case, Oracle can try to replicate your problem in house. It's hard to debug problems found through load testing without either a test case or artifacts from testing that provide enough data to identify the root cause.
Hi @alexkeh,
I've publish the project under: https://github.com/avrahamcool/PoolWithProxyApi I made some small modification - so it's clearer.
in order to replicate the problem:
you need to run the client from 2 simultaneous browsers. in each client - use a different user name with 100 concurrent connections. the problem should appear after some runs. (sometime all the 100 connections works - in that case just try again)
Thanks, @avrahamcool. We'll try out your test case. In the meantime, I've created bug 35999664 to track this issue.
ODP.NET 21.13 is now available on NuGet Gallery.
@alexkeh Thank you very much with all the help.
I have a similar problem as described here: https://github.com/oracle/dotnet-db-samples/issues/278 but with a different setup - enough to open a new issue.
I'm running a WebAPI project .net framework 4.8 Oracle.EntityFrameworkCore 3.19.180 Oracle.ManagedDataAccess.Core 2.19.210
I'm using a proxy user in order to connect to the DB, where each request can be made by a different user. I have a basic connection string, and in each request - I only swap the
USER ID
for the current request. I've noticed its using the same pool for all requests as expected.lets consider the following connection string: (notice the placeholder for the USER_ID):
MAX POOL SIZE=20;LOAD BALANCING=True;DECR POOL SIZE=100;INCR POOL SIZE=1;DATA SOURCE=MY_DB;PROXY PASSWORD=BLABLA123456;PROXY USER ID=MY_PROXY_USER;USER ID={0};
I've created a simple app to stress-test this setup. I have a single POST action that let you choose the user to be used in the connection. the action creates a DBContext, starts a transaction [THIS IS AN MPORTANT PART FOR THE BUG] inserts an object to the DB (with save changes) waits for 500ms [to imitate "long" requests.] commit the transaction
I also have a simple client that sends 100 request using USER_A, and 100 requests using USER_B - all in parallel. the server caps at 20 connections, as expected, but most of the requests works fine. because we are able to satisfy the request within the 15 seconds default timeout of the connection pool.
some of the requests fails with the following error:
ExceptionMessage: "Object reference not set to an instance of an object." ExceptionType: "System.NullReferenceException" StackTrace:
If I don't use a transaction, it's seems to work fine with the 200 parallel request described earlier. (I know hat for this simple use-case I don't even need a transaction - but in our real app we do need a transaction context - and I was able to reproduce the problem with this minimal setup]
here is the server code that i'm using: [I can upload the full test project, including the client to Github if necessary]