[jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ https://issues.apache.org/jira/browse/MODPYTHON-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494242 ] Graham Dumpleton commented on MODPYTHON-202: mod_python should perhaps simply be using 'ap_accept_lock_mech' instead of 'APR_LOCK_DEFAULT'. The value of 'ap_accept_lock_mech' is more likely by default to be correct for what type of MPM is being used, if not, it can be overridden using the existing AcceptMutex directive, which if 'APR_LOCK_DEFAULT' is wrong for the MPM being used would have to be done to get the MPM to work anyway. Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: https://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12449192 ] Jim Gallacher commented on MODPYTHON-202: - We seem to be going pretty far down the road with PythonOption and our new namespace, so I'm inclined to stick with that, unless there is some sort of performance implication. Jim Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: http://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448429 ] Sam Morris commented on MODPYTHON-202: -- I've done some more testing and it seems that APR_LOCK_PROC_PTHREAD semaphores will cause deadlocks when creating Session.Session objects if I hammer the refresh button too quickly in my browser (at intervals of less than about 0.2 seconds). The child processes are never killed by the parent server, and any further web requests will also hang while trying to grab the session sempahore. This remains the case even if I manually kill all the child processes (I guess the semaphore remains grabbed forever in the parent process). I rebuilt with the APR_LOCK_FCNTL type semaphore, and I can now hammer refresh as fast as possible (intervals of ~0.08 seconds) without seeing any deadlocks. I don't know whether this is because the PROC_PTHREAD semaphores are buggy, or whether the FCNTL semaphores are actually faster (fast enough to avoid the deadlock). Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: http://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448432 ] Sam Morris commented on MODPYTHON-202: -- BTW, I would prefer for the semaphore type to be configurable in the Apache configuration; then I wouldn't have to rebuild my distribution's mod_python packages to use them with the ITK MPM. If you'd accept such a patch then I'd be happy to try and implement it. Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: http://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585 ] Graham Dumpleton commented on MODPYTHON-202: A configuration option can possibly be modelled off how the AcceptMutex directive for Apache works. Ie: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex Would just need to decide whether we do it as a PythonOption or introduce a new directive instead. Note there is an interesting comment in there about using pthread which may be relevant to the problem you are seeing. Specifically: On most systems, when the pthread option is selected, if a child process terminates abnormally while holding the AcceptCntl mutex the server will stop responding to requests. When this occurs, the server will require a manual restart to recover. Solaris is a notable exception as it provides a mechanism, used by Apache, which usually allows the mutex to be recovered after a child process terminates abnormally while holding a mutex. If your system implements the pthread_mutexattr_setrobust_np() function, you may be able to use the pthread option safely. Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: http://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
Graham Dumpleton (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585 ] Graham Dumpleton commented on MODPYTHON-202: A configuration option can possibly be modelled off how the AcceptMutex directive for Apache works. Ie: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex Would just need to decide whether we do it as a PythonOption or introduce a new directive instead. We seem to be going pretty far down the road with PythonOption and our new namespace, so I'm inclined to stick with that, unless there is some sort of performance implication. Jim
