4 ms·
The article says the non-blocking read resolved the problem they were having while only introducing five microseconds of latency per borrow from the connection
by dub 6y ago
The article says the non-blocking read resolved the problem they were having while only introducing five microseconds of latency per borrow from the connection pool.
For a consumer-facing, latency-sensitive application, that sounds like much easier-to-stomach hack than introducing a network round-trip at the start of every connection borrow.
- user5994461 6y agoIt's funny you say it resolves the problem because if you read the bug report from the author opened since 2017 https://github.com/go-sql-driver/mysql/issues/657 https://github.com/go-sql-driver/mysql/issues/657 It's repeatedly pointed out by one maintainer that his server and application are misconfigured and should be fixed. Yet the author doesn't consider it and goes on a project to redo the connection pool (the library can certainly benefit from better error detection but he would be better off fixing the root cause of connections dropping). Ergo the issue is not fixed. If you look at the chart provided, it's still erroring every few minutes, instead of every minute. It's an improvement but a far cry from zero. https://user-images.githubusercontent.com/42793/57318792-6e3b6800-70fb-11e9-87f7-f9d69e8a3c7b.png https://user-images.githubusercontent.com/42793/57318792-6e3...
- yencabulator 6y agoThere's a fundamental unfixable race there: a connection can be picked from the pool while a FIN is already on its way to the client. This is "caused" (as in, not mitigated) by the intersection of a naive protocol, as pretty much all SQL protocols are, and the nature of distributed programming.
- user5994461 6y agoYou realize the database server was misconfigured to drop connections transparently after 30 seconds? If it were not for that, TCP race conditions are extremely rare.