MySql Connector throw an exception with a big concurrency volume

[yukozh]

[yukozh]

I'm using mysql on azure(5.7) which provided by Microsoft China Cloud Innovation Center officially. Disabled reset connection.

[yukozh]

Hi @bgrainger, @edwinsongmsft is the Principal Program Manager of Microsoft MySQL on Azure team. If you want to know what is the differences between normal MySQL and MySQL on Azure, you could communicate with him.

[edwinsongmsft]

Hi @bgrainger, as we did not support the auto reconnection, could u catch the exception and reconnect the database again? BR, Edwin

[bgrainger]

From the exception message, it seems like MySqlSession.TryPingAsync is being called on a session that is associated with a socket that already has an in-flight operation. I'm not exactly sure how to get into this situation; do you have more code that reproduces the problem that you can share?

[yukozh]

it occurred in a big concurrency volume. There was no particular code.

[caleblloyd]

Possible duplicate. This one uses MariaDB.

PomeloFoundation/Pomelo.EntityFrameworkCore.MySql#221

[bgrainger]

"There is already an open DataReader associated with this Connection" (from the linked issue) could indicate incorrect use of the library. If that is the root cause, then perhaps it's possible that it could also cause the "An asynchronous socket operation is already in progress" exception?

If so, a good troubleshooting step might be to add explicit checks in public APIs of MySqlConnector to detect this situation and throw a more helpful exception earlier.

OTOH, there could be a bug in this library that's causing both exceptions. If we add that code to throw the new exception and it's not getting thrown, that would discount the "incorrect use" hypothesis.

[caleblloyd]

Could this be coming from improperly disposed readers?

Do we force the reader to dispose when a connection is disposed? We might need to check the logic there. Since read buffering was added, we may need to add code to clear the read buffer as well.

[bgrainger]

Good call: MySqlConnection has HasActiveReader, but DoClose doesn't check it. (It will check if there's an active transaction and dispose (rollback) that.)

Disposing any active reader in MySqlConnection.DoClose may well work around this bug. (And once cancellation is actually correctly implemented, it may end up being more efficient to cancel the reader, rather than just read all its rows to the end.) And hopefully it wouldn't be too hard to reproduce this problem.

[caleblloyd]

Since read buffering was added, we may need to add code to clear the read buffer as well.

Adding Reader Disposal to MySqlConnection.DoClose will take care of reading through anything that is buffered as well.

[bgrainger]

Should be fixed in 0.14.1.

[yukozh]

@bgrainger There was another exception occurred with a big concurrency volume

[bgrainger]

This last exception is a duplicate of #162.

[yukozh]

@bgrainger When will you fix #162? Our customer case was blocked by this.

[bgrainger]

@kagamine Is it possible that your customer uses cancellation in any way, i.e., calls Async overloads with something other than CancellationToken.None? My working hypothesis is that this is related to currently-unimplemented cancellation support #3 but so far I have been unable to obtain a consistent repro to prove/disprove that.