This worklog has been replaced with mariadb.org/jira

This site is here for historical purposes only. Do not add or edit tasks here!

 
 
 

WorkLog Frontpage Log in / Register
High-Level Description | Task Dependencies | High-Level Specification | Low-Level Design | File Attachments | User Comments | Time Estimates | Funding and Votes | Progress Reports

 Growing pool of threads
Title
Task ID13
Queue
Version N/A
Status
PriorityN/A
Copies toSergei

Created byMonty08 Apr 2009Done
Supervisor N/A  
Lead Architect    
Architecture Review  
Implementor  
Code Review  
QA  
Documentation  
 High-Level Description
Solution(s) for avoiding deadlock when all threads in pool-of-threads are locked
or to busy to handle new queries.
 Task Dependencies
Others waiting for Task 13Task 13 is waiting forGraph
 
 High-Level Specification
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.
 Low-Level Design
 File Attachments
 NameTypeSizeByDate
 User Comments
 Time Estimates
NameHours WorkedLast Updated
Total0 
 Hrs WorkedProgressCurrentOriginal
This Task04040
Total04040
 
 Funding and Votes
Votes: 0: 0%
 Make vote: Useless    Nice to have    Important    Very important    

Funding: 0 offers, total 0 Euro
 Progress Reports
(Sergei - Thu, 01 Jul 2010, 06:15
    
Observers changed: Sergei

(Monty - Wed, 08 Apr 2009, 19:08
    
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.
 


Report Generator:
 
Saved Reports:

WorkLog v4.0.0
  © 2010  Sergei Golubchik and Monty Program AB
  © 2004  Andrew Sweger <yDNA@perlocity.org> and Addnorya
  © 2003  Matt Wagner <matt@mysql.com> and MySQL AB