-
Notifications
You must be signed in to change notification settings - Fork 341
Connectionpool not working as expected #495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Which version of MySqlConnector are you using? There was a very similar bug to this that was fixed in 0.38.0: #469. |
Thanks for the quick reply. I just updated today.
So I guess I already have that bugfix. But indeed, this sounds like the bug I have. |
Just to confirm: you’re saying that you do reproduce the problem with the latest code? |
I do not know if it's the exact same bug as the one you linked me to. I am using a high connection timeout, so cancellation does not seem to be a problem in my case. My problem seems to be that queries are finished, sessions are given back to the pool but the semaphore is not updated correctly. |
It's probably not; I just wanted to rule out that you weren't possibly running into that one (e.g., by using an older package version). |
Your code looks correct; I don't see an obvious reason why the connection pool would become exhausted even though sessions are being returned. Logs might help identify what's going on. Use |
Hey, I could reproduce the error with logging enabled:
Maybe you are seeing something suspicious. |
I can't explain how you're ending up in a state where Can you provide any more information about your table structure, types of commands, etc. that might help repro the problem? I assume |
Yes my MaximumPoolSize is 20. Program runs for about 1-5minutes. It is happening consistently. When it happens there are already tenthousands of queries executed. Another exception that is sometimes occuring is this:
Maybe it has something to do with the ConnectionPool situation? I have already finished my work without multithreading. When I have more time I could give debugging it another try. Maybe I can reproduce it on a minimal example. |
I think the smaller the connection pool is the faster the situation occurs.
These are counts of commands that have been executed when I get stuck. |
Please provide more details on this exception, including the full call stack.
It's quite possible that it's putting the connection pool into an inconsistent internal state and error handling needs to be improved. |
This is the full stacktrace for that exception. But that exception is not always happening when the deadlock happens, because I usually just let the program crash when it happens. I just thought that maybe it's another symptom for the same underlying problem, for example the server is sending invalid data? |
This could possibly be related to https://github.com/dotnet/corefx/issues/35393. |
Closing issue without a consistent repro on a very old version of the library. |
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I have a problem using MySqlConnector. I'm using this code as a wrapper around the library:
As you can see everything should be wrapped with a using-directive. And where it is not, CommandBehavior.CloseConnection should do the job, as I understand it. All usages of MySqlDataReader are also enclosed with a usage directive. Now the following situation ocurres:
My application which is doing alot of queries and writes in multiple threads (I am using Task.Run(...) for that) is working fine for a few minutes. Then I get the following situation:
All of my worker threads are waiting for the semaphore in
This is the state of the connection pool at that moment:
Why are there no leased sessions, twenty available sessions but the semaphore count is zero? I tried debugging this but I am not getting any further here. Maybe you have some idea?
On the server I am running 5.5.56-MariaDB, maybe thats the problem?
I am trying to run this on CentOS Linux release 7.4.1708 (Core) with Net Core Version 2.0.0. Both the application and the database run on the same server.
The text was updated successfully, but these errors were encountered: