Deadlock mechanism is not good enough for product requirement, for example, we hit such case that the UNLOCK TABLE is blocked outside due to WAITING+ACTIVE > overscrible+1. Schedule deadlock must be more philosophical.
Concurrency is not handled well also. For 32 groups, it’s a disaster if lots of BINLOG_DUMP for client/slave. Yes, we also hit this case. Limit special account or special handle in group are both solutions.
With the product experience, I think the essential issue that thread pool must handle is: the low priority queue must be scheduled in case of exception, and there must be a balance, the thread pool behavior and the legacy behavior.
Thread pool feature still needs product environment chasten, and we are enhancing it for our usage. I agree with most of the changes Inaam mentioned in this blog, and of course, looking forward the stable enhancement from Twitter:)
…
[Read more]