"Thoennes" wrote : | Dough Lea, the creator of the oswego-concurrent package, said the reason was an unsupported way how JBoss used the thread pool settings, but Adrian regarded it as a bug in the lib. |
It is a bug. Just because Doug no longer supports it, doesn't stop it being a bug. ;-) It is still a bug as well in the latest oswego concurrent, we just have a workaround that avoids the problem (we don't let the threadpool go empty through idle removal). The problem comes because you have something like: Scheduling thread: Are there any unused threads? Yes Idle Remover: Remove all the unused threads (they just timed out) Scheduling thread: Add the work for the now non-existant threads to pickup Result: Work is never performed It is a simple race condition. The check for unused threads and the addition of work are not synchronized (atomic). It is also NOT easy to fix because of the design of the code. Which is why Doug does not support it. The handling of idle threads in general is pretty poor in concurrent's executor. It is very difficult to achieve a controlled shutdown that doesn't leaving hanging/orphaned threads lying around. Again NOT easy to fix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3923131#3923131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3923131 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
