Hello. I submitted this patch last week and I'd just like to solicit comments on how to proceed. See this for the text of the bug and fix: https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
Unfortunately, I don't have a test that exhibits the bug that I can ask others to run. We were only able to see it when running a Loadrunner script emulating thousands of concurrent users. As I see it, there are two potential problems in the fix: 1) adding mutex() calls will single-thread code that previously was able to run on multiple processors and so imposes a performance hit. 2) There's a possibility of "deadly embrace" if some code path uses the locks in an order not seen in our tests. I think #2 would become evident pretty quickly if we were able to get a test run that exercises the mod_proxy code more fully than our one server. #1 I think is just overhead required for thread-safety. It would be nice if all apr-pools were required to only be accessed by a single thread, but if they aren't, then they must be serialized externally when there is the possibility of concurrent access. The presence of the "--enable-pool-concurrency-check" made fixing this problem a lot easier. I couldn't find a previous report of its use, but obviously someone thought it would be helpful. Let me know if there are questions I can answer about the patch or the core files that the bug produced. Thanks! -- Don Poitras - Host R&D SAS Institute Inc. SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677-4444 Cary, NC 27513
