You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/11/08 23:42:51 UTC
[jira] Created: (MODPYTHON-202) Allow mechanism used by global
mutex locks to be specified.
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.
Posted by "Jim Gallacher (JIRA)" <ji...@apache.org>.
[ 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.
Posted by "Sam Morris (JIRA)" <ji...@apache.org>.
[ 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.
Posted by "Sam Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481939 ]
Sam Morris commented on MODPYTHON-202:
--------------------------------------
I did some investigating today and it seems that a pthread_mutexattr_setrobust_np function was introduced in glibc 2.4, so mod_python could check for it at build time.
My platform (Debian) will stick with glibc 3.2 until the release of Debian 4.0 ("etch"), so I'm inclined to add a PythonOption for this 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.
Posted by "Sam Morris (JIRA)" <ji...@apache.org>.
[ 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
Re: [jira] Commented: (MODPYTHON-202) Allow mechanism used by global
mutex locks to be specified.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
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
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global
mutex locks to be specified.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global
mutex locks to be specified.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ 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.