Solution(s) for avoiding deadlock when all threads in pool-of-threads are locked or to busy to handle new queries.
From discussion between Monty & Jeremiah Gowdy Monty> In the future we have to also look at creating more pool-threads when Monty> all pool-threads gets locked by a handler. Jeremiah> This is a good solution IMO. You could base it on how long the next Jeremiah> queue item has been in the pool. So you determine a maximum latency Jeremiah> value that makes sense, and you grow the thread pool any time tasks are Jeremiah> waiting longer than that to execute, up to a certain number of threads Jeremiah> that would be your hard limit. Once you reach the hard limit, you Jeremiah> refuse to grow the pool further, and if no queries are being dequeued Jeremiah> after a long timeout, you could determine that things are deadlocked and Jeremiah> panic / start killing things, or let the user make that decision using Jeremiah> extra-port.
Observers changed: Sergei
High-Level Specification modified. --- /tmp/wklog.13.old.13623 2009-04-08 19:08:47.000000000 +0300 +++ /tmp/wklog.13.new.13623 2009-04-08 19:08:47.000000000 +0300 @@ -1 +1,15 @@ +From discussion between Monty & Jeremiah Gowdy + +Monty> In the future we have to also look at creating more pool-threads when +Monty> all pool-threads gets locked by a handler. + +Jeremiah> This is a good solution IMO. You could base it on how long the next +Jeremiah> queue item has been in the pool. So you determine a maximum latency +Jeremiah> value that makes sense, and you grow the thread pool any time tasks are +Jeremiah> waiting longer than that to execute, up to a certain number of threads +Jeremiah> that would be your hard limit. Once you reach the hard limit, you +Jeremiah> refuse to grow the pool further, and if no queries are being dequeued +Jeremiah> after a long timeout, you could determine that things are deadlocked and +Jeremiah> panic / start killing things, or let the user make that decision using +Jeremiah> extra-port.
