[jira] Commented: (MODPYTHON-78) No support for Apache 2.2 yet
[
http://issues.apache.org/jira/browse/MODPYTHON-78?page=comments#action_12364741
]
Jim Gallacher commented on MODPYTHON-78:
Unit Test Issue: KeepAliveTimeout
In htdocs/tests.py, test_server_members tests the value of KeepAliveTimeout.
The default value for KeepAliveTimeout changed in Apache 2.2 from 15 seconds to
5 seconds, so the test as written fails.
It would likely be better if KeepAliveTimeout configuration directive was used
to set an explicit value rather than relying on the default.
The offending test in tests.py starts at line 448::
log("server.keep_alive_timeout: %s" % `server.keep_alive_timeout`)
if server.keep_alive_timeout != 15.0:
self.fail("server.keep_alive_timeout should be 15.0")
> No support for Apache 2.2 yet
> -
>
> Key: MODPYTHON-78
> URL: http://issues.apache.org/jira/browse/MODPYTHON-78
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2
> Reporter: Nicolas Lehuen
> Fix For: 3.3
>
> See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some
> remarks by Jorey Bump, raised during the 3.2.1-BETA tests.
--
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-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=comments#action_12364737 ] Jim Gallacher commented on MODPYTHON-78: Unit Test Issue: mod_auth.so dependency mod_auth.so has been split into separate modules in Apache 2.2 (mod_auth_basic, mod_authn_file, mod_authz_user, and mod_authz_groupfile). test/test.py will need to be changed to use mod_auth_basic. > No support for Apache 2.2 yet > - > > Key: MODPYTHON-78 > URL: http://issues.apache.org/jira/browse/MODPYTHON-78 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Reporter: Nicolas Lehuen > Fix For: 3.3 > > See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some > remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- 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: mod_python as a mod_dav backend
And another one that seemed to vanish into thing air. On 31/01/2006, at 10:11 PM, Matt Carpenter wrote: > > > Graham Dumpleton wrote: >> Regardless of how you might use it, from a technical standpoint I >> would say that >> it is not going to be possible at present. >> >> One could imagine being able to write a separate C based Apache >> module which >> provides Python based wrappings for the DAV specific data >> structures that the >> repository hook function use. As documented in: >> >> http://docx.webperf.org/structdav__hooks__repository.html >> >> But, there are a few things missing. First, is there is no way to >> obtain references to >> the Python interpreter instances held by mod_python, the >> mechanisms for >> creating them and acquiring locks against them from a distinct >> Apache module. >> Similarly, there is there is no way to access the mod_python >> Python request_rec >> wrapper object etc. >> >> Both of these and possibly other stuff would be required. You do >> not want to go >> having to duplicate all this stuff as it sort of defeats the >> purpose and would >> possibly prevent use of mod_python and your module in the same Apache >> instance. >> >> What would be an interesting area for investigation in the future >> would be to >> work out whether there are functions within the mod_python module >> which could >> be exposed using the Apache APR_RETRIEVE_OPTIONAL_FN() interface. >> This would allow distinct modules to dynamically obtain references >> to some >> of the internals of mod_python so as to perhaps make use of all >> the machinery >> it has already for manipulating Python interpreters, as well as >> existing Python >> object wrappers for Apache structures. >> >> The end result would be the ability to create distinct C based >> Apache modules >> which themselves can also make use of Python by bootstrapping of >> mod_python. >> It may be tricky to work out how to do it and come up with a good >> interface design, >> but certainly would be interesting. >> >> Graham > How does mod_python hook into apache as it stands? Would it be > conceivably possible to have mod_python itself create the > dav_hooks_repository with a small patch to mod_python to provide a > new Python*Handler? > Apologies for the vagueness.. My knowledge of modular C programming > is very sketchy. It is technically possible to do it this way, ie., for mod_python to register hooks for dav, but this is highly unlikely to be acceptable as it means one is starting to lump into mod_python all this extra stuff which has nothing to do with its core purpose. It would just make things hard to maintain as for every mod_python release you then have to test all that extra stuff as well. If anything were to be done to allow working more closely with other Apache modules, the far preferable approach is that I outlined. That way mod_python has only to provide minimal generic module interface. All the hard stuff is then external to mod_python in modules maintained by other and doesn't impact development of mod_python itself. Matt, can you please keep the discussion cc'd to the mailing list, as probably of general interest. Graham
Re: 3.2.6 test period - how long do we wait?
Good enough for me. Shall we vote? If so I am: +1 Jim Graham Dumpleton wrote: I am having problems with posts to python-dev mailing list from home occassionally disappearing in a black hole. Thus my post on this topic before Jim brought it up in the first place vanished. What I has said was: this code runs smoothly, i.e. no segfaults, all tests passed: FreeBSD 4.9: Apache/2.0.50 (prefork) Python/2.3.4 Apache/2.0.55 (prefork) Python/2.4.2 Okay, this is good. If there is a general consensus that this is a reasonable solution, the question is what should be done with 3.2.6. Should it be released with this problem in it and fix it later in 3.3? Personally, I really don't think that connection handlers in mod_python get used by anyone and so don't see a pressing need to go fixing it right now. Thus I would say go with 3.2.6 as final with how it is. Is there anything else of concern that is holding us up now on an official release of 3.2.6? In other words, I agree with Nicolas, we should just release it. If someone actually came up and said they were using connection handlers for something significant, then I might change this view, but I doubt anyone is using them. I would also point out that JIRA lists lots of other issues, some of them minor and trivial to fix but which would be more worthwhile than fixing than this connection handler issue. We have already said we will defer these in the interest of getting a final version of 3.2 out sooner rather than later. Thus, as much as I would prefer to see as much as possible fixed, I think we just have defer further changes to next version. Graham Jim Gallacher wrote .. Nicolas Lehuen wrote: OK, so shall we schedule the 3.2.x release for 2007, then ? As for the Apache 2.2 version, what if we roll in your suggested patch, Jim, then discover a bunch of problem related to it during the beta tests ? Will we wait until they are all fixed to release the 3.2 version ? Apache 2.2 is quite new so we'll likely to have to squish bugs, due for example to new interaction between Apache filters and mod_python. That's a wild guess but filters have been modified in Apache 2.2 so I'm sure something evil lurks there. I'm totally happy to defer changes for Apache 2.2 as I don't personally plan on migrating any time soon. The only reason I brought it up is that some of the code which seems to be causing issues for Apache 2.2 happens to reside in connobject.c, which is an area of interest for the _conn_read issue. Even if we were to roll fixes for apache 2.2 into mp 3.2, I'm not suggesting we advertise apache 2.2 compatibility just yet. Or we could simply forget about making the release one day and tell every user to use the latest snapshot from subversion. Sorry to be like that, but we have users out there that would be perfectly happy with the current state of the 3.2.6 version, and a lot of our answers on the mailing list are "yup, we know this bug, it's already been fixed one year ago, but don't worry, you'll get the bugfix soon enough". Point taken, and it is a very good point indeed. Once again, it seems that no regression have been introduced in 3.2.6 vs 3.1.4, so we should release it ASAP and try to keep a steady release rythm afterwards. When we'll get momentum we'll solve a bunch of problem pretty fast, but it's been a year now that we are paralysed by perfectionism. What could be worse than leaving our users out there with the current 3.1.4 version ? I *still* wonder why the whole ConnectionHandler issue was not seen on FreeBSD with mp 3.1.4 though. I'll need to check the svn logs again but I'm pretty sure this is not a new unit test. That being said I'm not personally concerned about this issue since it doesn't affect every platform (or more selfishly I should say it doesn't affect the OS I'm working on) and I suspect that not many people are directly interacting with the connection object. What's that old line about open source software... Release early, release often? Jim 2006/1/31, Jim Gallacher <[EMAIL PROTECTED]>: I assume we will be doing a 3.2.7 release if Graham's fix for the ConnectionHandler / MODPYTHON-102 problem works? If that is the case I wonder if we should roll in the changes to support apache 2.2. I scanned mod_python for deprecated or removed apr calls and can find only one (apr_sockaddr_port_get), plus the missing APR_STATUS_IS_SUCCESS macro. The original macro is: #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ || (s) == APR_OS_START_SYSERR + NO_ERROR) The discussion on httpd-dev suggested that this macro should be substituted with a simple test such as "if (rc != APR_SUCCESS)", and the '||' condition was not likely used. So that we are making the fewest possible changes to our current 3.2 codebase, I'd suggest reimplenting APR_STATUS_IS_SUCCESS in our code, and then removing it 3.3. This will give us lot's of time as we work on 3.3 to discover if the
Re: mod_python as a mod_dav backend
This is a resend to python-dev list of an email I sent yesterday. For some reason oaccsional email I am sending to list from home is dissappearing, although people cc'd it are getting it. Apologies if this is a duplicate. On 30/01/2006, at 9:49 PM, Matt Carpenter wrote: > Graham Dumpleton wrote: >> Others may know what you are talking about, but I plead ignorance. >> Can >> you perhaps describe further what you are talking about, how it >> would be >> used etc. A URL to stuff that could be read to understand similar >> things >> would also help. >> >> Graham > What I am trying to achieve: > I'm writing a module for our system for managing documents that're > attached to records in our database, updates to these documents are > recorded into the database along with what user made the user that > made the edit, and various other information depending on what type > of document (the system manages templates, and mailmerges with > virtual .csv files pulling data from the database as well). The > directory structure is entirely virtual, the structure on the > servers is just a few directories for each type of file, and the > files are named after their record in the database. > mod_dav implements hooks (see http://mailman.lyra.org/pipermail/dav- > dev/2005-April/005926.html), but I'm not a C programmer, so I'd > like a these hooks to be able to call python functions instead. > Hope that makes sense. Regardless of how you might use it, from a technical standpoint I would say that it is not going to be possible at present. One could imagine being able to write a separate C based Apache module which provides Python based wrappings for the DAV specific data structures that the repository hook function use. As documented in: http://docx.webperf.org/structdav__hooks__repository.html But, there are a few things missing. First, is there is no way to obtain references to the Python interpreter instances held by mod_python, the mechanisms for creating them and acquiring locks against them from a distinct Apache module. Similarly, there is there is no way to access the mod_python Python request_rec wrapper object etc. Both of these and possibly other stuff would be required. You do not want to go having to duplicate all this stuff as it sort of defeats the purpose and would possibly prevent use of mod_python and your module in the same Apache instance. What would be an interesting area for investigation in the future would be to work out whether there are functions within the mod_python module which could be exposed using the Apache APR_RETRIEVE_OPTIONAL_FN() interface. This would allow distinct modules to dynamically obtain references to some of the internals of mod_python so as to perhaps make use of all the machinery it has already for manipulating Python interpreters, as well as existing Python object wrappers for Apache structures. The end result would be the ability to create distinct C based Apache modules which themselves can also make use of Python by bootstrapping of mod_python. It may be tricky to work out how to do it and come up with a good interface design, but certainly would be interesting. Graham
Re: 3.2.6 test period - how long do we wait?
I am having problems with posts to python-dev mailing list from home occassionally disappearing in a black hole. Thus my post on this topic before Jim brought it up in the first place vanished. What I has said was: >> this code runs smoothly, i.e. no segfaults, all tests passed: >> FreeBSD 4.9: >> >> Apache/2.0.50 (prefork) Python/2.3.4 >> Apache/2.0.55 (prefork) Python/2.4.2 > > Okay, this is good. > > If there is a general consensus that this is a reasonable solution, > the question is what should be done with 3.2.6. Should it be released > with this problem in it and fix it later in 3.3? > > Personally, I really don't think that connection handlers in > mod_python get used by anyone and so don't see a pressing need to go > fixing it right now. Thus I would say go with 3.2.6 as final with how > it is. > > Is there anything else of concern that is holding us up now on an > official release of 3.2.6? In other words, I agree with Nicolas, we should just release it. If someone actually came up and said they were using connection handlers for something significant, then I might change this view, but I doubt anyone is using them. I would also point out that JIRA lists lots of other issues, some of them minor and trivial to fix but which would be more worthwhile than fixing than this connection handler issue. We have already said we will defer these in the interest of getting a final version of 3.2 out sooner rather than later. Thus, as much as I would prefer to see as much as possible fixed, I think we just have defer further changes to next version. Graham Jim Gallacher wrote .. > Nicolas Lehuen wrote: > > OK, so shall we schedule the 3.2.x release for 2007, then ? > > > > As for the Apache 2.2 version, what if we roll in your suggested > > patch, Jim, then discover a bunch of problem related to it during the > > beta tests ? Will we wait until they are all fixed to release the 3.2 > > version ? Apache 2.2 is quite new so we'll likely to have to squish > > bugs, due for example to new interaction between Apache filters and > > mod_python. That's a wild guess but filters have been modified in > > Apache 2.2 so I'm sure something evil lurks there. > > I'm totally happy to defer changes for Apache 2.2 as I don't personally > plan on migrating any time soon. The only reason I brought it up is that > some of the code which seems to be causing issues for Apache 2.2 happens > to reside in connobject.c, which is an area of interest for the > _conn_read issue. Even if we were to roll fixes for apache 2.2 into mp > 3.2, I'm not suggesting we advertise apache 2.2 compatibility just yet. > > > > Or we could simply forget about making the release one day and > > tell every user to use the latest snapshot from subversion. Sorry to > > be like that, but we have users out there that would be perfectly > > happy with the current state of the 3.2.6 version, and a lot of our > > answers on the mailing list are "yup, we know this bug, it's already > > been fixed one year ago, but don't worry, you'll get the bugfix soon > > enough". > > Point taken, and it is a very good point indeed. > > > Once again, it seems that no regression have been introduced in 3.2.6 > > vs 3.1.4, so we should release it ASAP and try to keep a steady > > release rythm afterwards. When we'll get momentum we'll solve a bunch > > of problem pretty fast, but it's been a year now that we are paralysed > > by perfectionism. What could be worse than leaving our users out there > > with the current 3.1.4 version ? > > I *still* wonder why the whole ConnectionHandler issue was not seen on > FreeBSD with mp 3.1.4 though. I'll need to check the svn logs again but > I'm pretty sure this is not a new unit test. > > That being said I'm not personally concerned about this issue since it > doesn't affect every platform (or more selfishly I should say it doesn't > affect the OS I'm working on) and I suspect that not many people are > directly interacting with the connection object. > > What's that old line about open source software... Release early, > release often? > > Jim > > > 2006/1/31, Jim Gallacher <[EMAIL PROTECTED]>: > > > >>I assume we will be doing a 3.2.7 release if Graham's fix for the > >>ConnectionHandler / MODPYTHON-102 problem works? > >> > >>If that is the case I wonder if we should roll in the changes to support > >>apache 2.2. I scanned mod_python for deprecated or removed apr calls > and > >>can find only one (apr_sockaddr_port_get), plus the missing > >>APR_STATUS_IS_SUCCESS macro. > >> > >>The original macro is: > >> > >>#define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ > >> || (s) == APR_OS_START_SYSERR + NO_ERROR) > >> > >> > >>The discussion on httpd-dev suggested that this macro should be > >>substituted with a simple test such as "if (rc != APR_SUCCESS)", and > the > >>'||' condition was not likely used. So that we are making the fewest > >>possible changes to our current 3.2 codebase
[jira] Commented: (MODPYTHON-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=comments#action_12364730 ] Jim Gallacher commented on MODPYTHON-78: I thought I could edit a JIRA comment but perhaps not. Anyway, the above should read: Apache 2.2 now uses apr 1.x (Apache 2.0 used 0.9x) from which APR_STATUS_IS_SUCCESS has been removed. > No support for Apache 2.2 yet > - > > Key: MODPYTHON-78 > URL: http://issues.apache.org/jira/browse/MODPYTHON-78 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Reporter: Nicolas Lehuen > Fix For: 3.3 > > See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some > remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- 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-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=comments#action_12364708 ] Jim Gallacher commented on MODPYTHON-78: I scanned mod_python 3.2.6 for the existence of other deprecated apr functions listed in the APR change log and nothing else is turning up. I'll comment on the APR_STATUS_IS_SUCCESS issue separately. > No support for Apache 2.2 yet > - > > Key: MODPYTHON-78 > URL: http://issues.apache.org/jira/browse/MODPYTHON-78 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Reporter: Nicolas Lehuen > Fix For: 3.3 > > See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some > remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- 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: Fwd: Contact request from Nokia Opensource / Research site user.
This is pretty cool. Thanks for taking the time to make the contact Nicolas. (And thanks to Johan for responding). Jim Nicolas Lehuen wrote: FYI, Johan Wikman from Nokia answered my request. He's OK for us to brag about mod_python 3.1.3 running on the Nokia S60 platform, though he doesn't want to be quoted directly. The fun part is that he'd like to know when we'll support Apache 2.2 :) Regards, Nicolas
Re: 3.2.6 test period - how long do we wait?
Deron Meranda wrote: On 1/31/06, Jim Gallacher <[EMAIL PROTECTED]> wrote: apache 2.2. I scanned mod_python for deprecated or removed apr calls and can find only one (apr_sockaddr_port_get), plus the missing APR_STATUS_IS_SUCCESS macro. The apr_sockaddr_port_get() call was introduced by me to support IPv6 in modpython with MODPYTHON-64. Looking at the APR 1.0 CHANGES file (accompaning httpd 2.2): *) The following deprecated interfaces have been removed: apr_sockaddr_port_get-> (access directly) I'm trying to review the APR source to see exactly what that means and the conditions under which it's safe. We don't want to accidentally pull the wrong field and have endianness problems. BTW, I want to get this one fixed before release rather than reverting to the pre-MODPYTHON-64 code...or we'll break under IPv6 again. I say we leave it as is (ie continue use apr_sockaddr_port_get) and worry about it when we do some sort of comprehensive review for apache 2.2 compatibility. Jim
Re: 3.2.6 test period - how long do we wait?
Nicolas Lehuen wrote: OK, so shall we schedule the 3.2.x release for 2007, then ? As for the Apache 2.2 version, what if we roll in your suggested patch, Jim, then discover a bunch of problem related to it during the beta tests ? Will we wait until they are all fixed to release the 3.2 version ? Apache 2.2 is quite new so we'll likely to have to squish bugs, due for example to new interaction between Apache filters and mod_python. That's a wild guess but filters have been modified in Apache 2.2 so I'm sure something evil lurks there. I'm totally happy to defer changes for Apache 2.2 as I don't personally plan on migrating any time soon. The only reason I brought it up is that some of the code which seems to be causing issues for Apache 2.2 happens to reside in connobject.c, which is an area of interest for the _conn_read issue. Even if we were to roll fixes for apache 2.2 into mp 3.2, I'm not suggesting we advertise apache 2.2 compatibility just yet. Or we could simply forget about making the release one day and tell every user to use the latest snapshot from subversion. Sorry to be like that, but we have users out there that would be perfectly happy with the current state of the 3.2.6 version, and a lot of our answers on the mailing list are "yup, we know this bug, it's already been fixed one year ago, but don't worry, you'll get the bugfix soon enough". Point taken, and it is a very good point indeed. Once again, it seems that no regression have been introduced in 3.2.6 vs 3.1.4, so we should release it ASAP and try to keep a steady release rythm afterwards. When we'll get momentum we'll solve a bunch of problem pretty fast, but it's been a year now that we are paralysed by perfectionism. What could be worse than leaving our users out there with the current 3.1.4 version ? I *still* wonder why the whole ConnectionHandler issue was not seen on FreeBSD with mp 3.1.4 though. I'll need to check the svn logs again but I'm pretty sure this is not a new unit test. That being said I'm not personally concerned about this issue since it doesn't affect every platform (or more selfishly I should say it doesn't affect the OS I'm working on) and I suspect that not many people are directly interacting with the connection object. What's that old line about open source software... Release early, release often? Jim 2006/1/31, Jim Gallacher <[EMAIL PROTECTED]>: I assume we will be doing a 3.2.7 release if Graham's fix for the ConnectionHandler / MODPYTHON-102 problem works? If that is the case I wonder if we should roll in the changes to support apache 2.2. I scanned mod_python for deprecated or removed apr calls and can find only one (apr_sockaddr_port_get), plus the missing APR_STATUS_IS_SUCCESS macro. The original macro is: #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ || (s) == APR_OS_START_SYSERR + NO_ERROR) The discussion on httpd-dev suggested that this macro should be substituted with a simple test such as "if (rc != APR_SUCCESS)", and the '||' condition was not likely used. So that we are making the fewest possible changes to our current 3.2 codebase, I'd suggest reimplenting APR_STATUS_IS_SUCCESS in our code, and then removing it 3.3. This will give us lot's of time as we work on 3.3 to discover if there are any problems droping the APR_OS_START_SYSERR part of the test. Jim
Re: 3.2.6 test period - how long do we wait?
On Tue, 31 Jan 2006, Jim Gallacher wrote: I assume we will be doing a 3.2.7 release if Graham's fix for the ConnectionHandler / MODPYTHON-102 problem works? Unfortunately, the answer is yes... As much as we'd like to release it sooner, I think it's important to not loose the perspective that quality over speed is what we favor. In other words - if it takes a little longer to get the quality we want, then that's just fine. :-) Grisha
Re: 3.2.6 test period - how long do we wait?
On 1/31/06, Deron Meranda <[EMAIL PROTECTED]> wrote: > On 1/31/06, Jim Gallacher <[EMAIL PROTECTED]> wrote: > > apache 2.2. I scanned mod_python for deprecated or removed apr calls and > > can find only one (apr_sockaddr_port_get), plus the missing > > APR_STATUS_IS_SUCCESS macro. > > The apr_sockaddr_port_get() call was introduced by me to support > IPv6 in modpython with MODPYTHON-64. Okay, the correct fix for apr_sockaddr_port_get() which works under both Apache 2.0 and 2.2 is to replace the single call in connobject.c, apr_sockaddr_port_get(&port, addr); with port = addr->port; I've added this information to MODPYTHON-78 notes (httpd 2.2 port). Of course that fix only *needs* to be made when 2.2 is completely addressed, but it can be safely rolled in before then too. -- Deron Meranda
[jira] Commented: (MODPYTHON-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=comments#action_12364671 ] Deron Meranda commented on MODPYTHON-78: One small incompatibility is the call to the APR function apr_sockaddr_port_get(), as introduced in the fix for bug MODPYTHON-64. That function was deprecated in APR 1.0 (which maked it into httpd 2.2). The changelog for APR says: *) The following deprecated interfaces have been removed: apr_sockaddr_port_get-> (access directly) After reviewing the APR changes, it appears that the correct fix to mod_python is quite simple. The line in connobject.c: apr_sockaddr_port_get(&port, addr); should be replaced with port = addr->port; This is still portable and has no endianness or word-size issues. (as it would if it tried accessing the addr->sa sub-struct directly). > No support for Apache 2.2 yet > - > > Key: MODPYTHON-78 > URL: http://issues.apache.org/jira/browse/MODPYTHON-78 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Reporter: Nicolas Lehuen > Fix For: 3.3 > > See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some > remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- 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: 3.2.6 test period - how long do we wait?
On 1/31/06, Jim Gallacher <[EMAIL PROTECTED]> wrote: > apache 2.2. I scanned mod_python for deprecated or removed apr calls and > can find only one (apr_sockaddr_port_get), plus the missing > APR_STATUS_IS_SUCCESS macro. The apr_sockaddr_port_get() call was introduced by me to support IPv6 in modpython with MODPYTHON-64. Looking at the APR 1.0 CHANGES file (accompaning httpd 2.2): *) The following deprecated interfaces have been removed: apr_sockaddr_port_get-> (access directly) I'm trying to review the APR source to see exactly what that means and the conditions under which it's safe. We don't want to accidentally pull the wrong field and have endianness problems. BTW, I want to get this one fixed before release rather than reverting to the pre-MODPYTHON-64 code...or we'll break under IPv6 again. -- Deron Meranda
Fwd: Contact request from Nokia Opensource / Research site user.
FYI, Johan Wikman from Nokia answered my request. He's OK for us to brag about mod_python 3.1.3 running on the Nokia S60 platform, though he doesn't want to be quoted directly. The fun part is that he'd like to know when we'll support Apache 2.2 :) Regards, Nicolas -- Forwarded message -- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 31 janv. 2006 10:10 Subject: RE: Contact request from Nokia Opensource / Research site user. To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Hi Nicolas, Sorry for not responding earlier but I have been out of the office for the last two weeks. >I'm on the mod_python development team, and someone from the >mailing list told us about your incredible port. > >Could you give us a bit of information on the subject, like >what is the version you ported (we're currently releasing the >3.2.6 with a bunch of bugfixes), any difficulty you >encountered, things you think we could improve to make your >life easier, or things you might want to contribute to the project? First, I can't take credit for the mod_python porting as that was made by Antoine Trux. Antoine does no longer work in the project but he may still remember more than I know:) The version of mod_python that we use is 3.1.3. That was the most recent one when the porting was made (in the beginning of last year). As porting mod_python is not the primary goal of our project we have not taken more recent versions into use. Antoine might provide more details but I'd say the biggest issues were to figure out how mod_python works, work out how to interface it with Python for S60 and to deal with certain limitations of Python for S60. The amount of code changes is surpricingly small. >We would also liketo know if we could talk about your work >when we make the announcement about the new release - >something along the lines of "mod_python is so portable it can >even run on your favorite mobile phone thanks to the work of >Nokia" and so on and so forth (we love to boast like that ;). >I cannot sign anything on behalf of the Apache Foundation, so >that's only a prospective question, not a binding one ;). As far as I am concerned you can make any statements you like that (as the statement above) are based on information that is public. However, at this point I would not like to provide you with a quote:) Btw, does mod_python work with the Apache 2.2 branch? I will soon take that version into use. >In any case, kudos for your work ! > >(I cc this to mod_python developers mailing list) That CC did not come through so perhaps you can forward to the list what you think is relevant. Best regards, Johan
Re: 3.2.6 test period - how long do we wait?
On Tue, 2006-01-31 at 17:59 +0100, Nicolas Lehuen wrote: > Once again, it seems that no regression have been introduced in 3.2.6 > vs 3.1.4, so we should release it ASAP and try to keep a steady > release rythm afterwards. When we'll get momentum we'll solve a bunch > of problem pretty fast, but it's been a year now that we are paralysed > by perfectionism. What could be worse than leaving our users out there > with the current 3.1.4 version ? +1 :) Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/
Re: 3.2.6 test period - how long do we wait?
OK, so shall we schedule the 3.2.x release for 2007, then ? As for the Apache 2.2 version, what if we roll in your suggested patch, Jim, then discover a bunch of problem related to it during the beta tests ? Will we wait until they are all fixed to release the 3.2 version ? Apache 2.2 is quite new so we'll likely to have to squish bugs, due for example to new interaction between Apache filters and mod_python. That's a wild guess but filters have been modified in Apache 2.2 so I'm sure something evil lurks there. Or we could simply forget about making the release one day and tell every user to use the latest snapshot from subversion. Sorry to be like that, but we have users out there that would be perfectly happy with the current state of the 3.2.6 version, and a lot of our answers on the mailing list are "yup, we know this bug, it's already been fixed one year ago, but don't worry, you'll get the bugfix soon enough". Once again, it seems that no regression have been introduced in 3.2.6 vs 3.1.4, so we should release it ASAP and try to keep a steady release rythm afterwards. When we'll get momentum we'll solve a bunch of problem pretty fast, but it's been a year now that we are paralysed by perfectionism. What could be worse than leaving our users out there with the current 3.1.4 version ? Regards, Nicolas 2006/1/31, Jim Gallacher <[EMAIL PROTECTED]>: > I assume we will be doing a 3.2.7 release if Graham's fix for the > ConnectionHandler / MODPYTHON-102 problem works? > > If that is the case I wonder if we should roll in the changes to support > apache 2.2. I scanned mod_python for deprecated or removed apr calls and > can find only one (apr_sockaddr_port_get), plus the missing > APR_STATUS_IS_SUCCESS macro. > > The original macro is: > > #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ > || (s) == APR_OS_START_SYSERR + NO_ERROR) > > > The discussion on httpd-dev suggested that this macro should be > substituted with a simple test such as "if (rc != APR_SUCCESS)", and the > '||' condition was not likely used. So that we are making the fewest > possible changes to our current 3.2 codebase, I'd suggest reimplenting > APR_STATUS_IS_SUCCESS in our code, and then removing it 3.3. This will > give us lot's of time as we work on 3.3 to discover if there are any > problems droping the APR_OS_START_SYSERR part of the test. > > Jim >
Re: 3.2.6 test period - how long do we wait?
I assume we will be doing a 3.2.7 release if Graham's fix for the ConnectionHandler / MODPYTHON-102 problem works? If that is the case I wonder if we should roll in the changes to support apache 2.2. I scanned mod_python for deprecated or removed apr calls and can find only one (apr_sockaddr_port_get), plus the missing APR_STATUS_IS_SUCCESS macro. The original macro is: #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ || (s) == APR_OS_START_SYSERR + NO_ERROR) The discussion on httpd-dev suggested that this macro should be substituted with a simple test such as "if (rc != APR_SUCCESS)", and the '||' condition was not likely used. So that we are making the fewest possible changes to our current 3.2 codebase, I'd suggest reimplenting APR_STATUS_IS_SUCCESS in our code, and then removing it 3.3. This will give us lot's of time as we work on 3.3 to discover if there are any problems droping the APR_OS_START_SYSERR part of the test. Jim
Re: Segfaults in ConnectionHander (Possible Solution)
Jim Gallacher wrote:
Volodya wrote:
On Mon, Jan 30, 2006 at 09:40:39PM -0500, Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Extending the above code as:
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ,
bufsize);
Py_END_ALLOW_THREADS;
if (! APR_STATUS_IS_SUCCESS(rc)) {
PyErr_SetObject(PyExc_IOError,
PyString_FromString("Connection read error"));
return NULL;
}
/* Return empty string if no buckets. Can be caused by EAGAIN. */
if (APR_BRIGADE_EMPTY(bb)) {
return PyString_FromString("");
}
seems to fix the problem. Ie., use call to APR_BRIGADE_EMPTY(bb) to
check
whether any new buckets added and returning empty string if not.
Okay, this may work, but the EAGAIN propogating backup as an empty
string to Python can cause a tight loop to occur where calls are going
out and back into Python code. This will occur until something is read
or an error occurs.
To avoid the back and forth, another option may be:
while (APR_BRIGADE_EMPTY(bb)) {
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c->input_filters, bb, mode,
APR_BLOCK_READ, bufsize);
Py_END_ALLOW_THREADS;
if (! APR_STATUS_IS_SUCCESS(rc)) {
PyErr_SetObject(PyExc_IOError,
PyString_FromString("Connection read
error"));
return NULL;
}
}
Graham,
this code runs smoothly, i.e. no segfaults, all tests passed:
FreeBSD 4.9:
That's good news. I still wonder why we are seeing this problem in 3.2
and 3.1.4 though.
And what I meant to say was "and *NOT* in 3.1.4".
Jim
Re: Segfaults in ConnectionHander (Possible Solution)
Volodya wrote:
On Mon, Jan 30, 2006 at 09:40:39PM -0500, Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Extending the above code as:
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);
Py_END_ALLOW_THREADS;
if (! APR_STATUS_IS_SUCCESS(rc)) {
PyErr_SetObject(PyExc_IOError,
PyString_FromString("Connection read error"));
return NULL;
}
/* Return empty string if no buckets. Can be caused by EAGAIN. */
if (APR_BRIGADE_EMPTY(bb)) {
return PyString_FromString("");
}
seems to fix the problem. Ie., use call to APR_BRIGADE_EMPTY(bb) to check
whether any new buckets added and returning empty string if not.
Okay, this may work, but the EAGAIN propogating backup as an empty
string to Python can cause a tight loop to occur where calls are going
out and back into Python code. This will occur until something is read
or an error occurs.
To avoid the back and forth, another option may be:
while (APR_BRIGADE_EMPTY(bb)) {
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);
Py_END_ALLOW_THREADS;
if (! APR_STATUS_IS_SUCCESS(rc)) {
PyErr_SetObject(PyExc_IOError,
PyString_FromString("Connection read error"));
return NULL;
}
}
Graham,
this code runs smoothly, i.e. no segfaults, all tests passed:
FreeBSD 4.9:
That's good news. I still wonder why we are seeing this problem in 3.2
and 3.1.4 though.
Jim
[jira] Commented: (MODPYTHON-102) Bus error with connection handler on secondary port.
[
http://issues.apache.org/jira/browse/MODPYTHON-102?page=comments#action_12364549
]
Graham Dumpleton commented on MODPYTHON-102:
After much digging, documented at:
http://www.mail-archive.com/python-dev@httpd.apache.org/msg01062.html
http://www.mail-archive.com/python-dev@httpd.apache.org/msg01064.html
http://www.mail-archive.com/python-dev@httpd.apache.org/msg01065.html
Problem found to be because initial read from connection could return EAGAIN
but _conn_read() wasn't dealing with that case. The code needed to be checking
for the bucket brigade being empty.
Suggested fix to _conn_read() is to use:
while (APR_BRIGADE_EMPTY(bb)) {
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ,
bufsize);
Py_END_ALLOW_THREADS;
if (! APR_STATUS_IS_SUCCESS(rc)) {
PyErr_SetObject(PyExc_IOError,
PyString_FromString("Connection read error"));
return NULL;
}
}
Note also that bug also found in buffer resizing code. See:
http://www.mail-archive.com/python-dev@httpd.apache.org/msg01050.html
Specifically:
if (len == 0 && bytes_read == bufsize) {
_PyString_Resize(&result, bufsize + HUGE_STRING_LEN);
buffer = PyString_AS_STRING((PyStringObject *) result);
buffer += bufsize;
bufsize += HUGE_STRING_LEN;
}
The "buffer" was being offset by HUGE_STRING_LEN before when it should have
been bufsize (or bytes_read).
> Bus error with connection handler on secondary port.
>
>
> Key: MODPYTHON-102
> URL: http://issues.apache.org/jira/browse/MODPYTHON-102
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2
> Environment: Mas OS X 10.3 (Panther)
> Reporter: Graham Dumpleton
>
> Logging this one for posterity as hardly likely that anyone would use
> connection handlers with mod_python for anything meaningful.
> Basic problem is that use of connection handler on secondary listener port is
> resulting in a bus error deep in Apache code when it tries to read data from
> the connection. The problem initially only seems to be present on Mac OS X
> 10.3. The problem could not be duplicated on Linux. On Mac OS X the problem
> occurred with both Apache 2.0.51 and 2.0.55 in both prefork and worker MPM
> modes.
> The connection handler code that was being used was:
> from mod_python import apache
> def connectionhandler(conn):
> apache.log_error("connectionhandler")
> try:
> while 1:
> #conn.write(conn.readline())
> conn.write(conn.read())
> except IOError:
> pass
> return apache.OK
> If this is enabled for the default listener port for Apache, ie., simply add
> in main Apache config:
> PythonPath '["/Users/grahamd/Sites/add_handler"]+sys.path'
> PythonConnectionHandler example::connectionhandler
> The connection handler works and is equivalent to mod_echo.
> If however the connection handler is run on a secondary port, a bus error
> occurs when read() or readline() is called by the connection handler. Ie.,
> Listen 8081
> PythonPath '["/Users/grahamd/Sites/add_handler"]+sys.path'
>
> PythonConnectionHandler example::connectionhandler
>
> Output from gdb is below. Note that if the connection handler simply returns
> apache.DECLINED, everything is okay and Apache will serve up pages fine, only
> when doing read of data from connection handler does it decide to crash.
> (gdb) cont
> Continuing.
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> [Switching to process 2342 thread 0xc03]
> 0x0058 in ?? ()
> (gdb) where
> #0 0x0058 in ?? ()
> Cannot access memory at address 0x58
> Cannot access memory at address 0x58
> #1 0x006068f8 in _conn_read (c=0x1933014, mode=AP_MODE_READBYTES, len=0) at
> connobject.c:117
> #2 0x00606b04 in conn_read (self=0x471da0, args=0xf0101140) at
> connobject.c:177
> #3 0x95fa94a8 in PyEval_GetFuncDesc ()
> #4 0x95fa6c64 in PyEval_EvalCode ()
> #5 0x95fa9728 in PyEval_GetFuncDesc ()
> #6 0x95fa9580 in PyEval_GetFuncDesc ()
> #7 0x95fa6c64 in PyEval_EvalCode ()
> #8 0x95fa9728 in PyEval_GetFuncDesc ()
> #9 0x95fa9580 in PyEval_GetFuncDesc ()
> #10 0x95fa6c64 in PyEval_EvalCode ()
> #11 0x95fa7e30 in PyEval_EvalCodeEx ()
> #12 0x95fa97dc in PyEval_GetFuncDesc ()
> #13 0x95fa9580 in PyEval_GetFuncDesc ()
> #14 0x95fa6c64 in PyEval_EvalCode ()
> #15 0x95fa7e30 in PyEval_EvalCodeEx ()
> #16 0x95f5f354 in PyFunction_SetClosure ()
> #17 0x95f4a8d0 in PyObject_Call ()
> #18 0x95f529e8 in PyMethod_New ()
> #19 0x95f4a8d0 in PyObject_Call ()
> #20 0x95f4ab7c in PyObject_CallMethod ()
> #21 0x0060eab0 in python_connection (con=0x192c540) at mod_python.c:1313
> #22 0x0003fce4 in ap_run_process_connection (c=0x192c540) at connection.c:42
> #23
Re: Segfaults in ConnectionHander (Possible Solution)
On Mon, Jan 30, 2006 at 09:40:39PM -0500, Graham Dumpleton wrote:
> Graham Dumpleton wrote ..
> > Extending the above code as:
> >
> > Py_BEGIN_ALLOW_THREADS;
> > rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ,
> > bufsize);
> > Py_END_ALLOW_THREADS;
> >
> > if (! APR_STATUS_IS_SUCCESS(rc)) {
> > PyErr_SetObject(PyExc_IOError,
> > PyString_FromString("Connection read error"));
> > return NULL;
> > }
> >
> > /* Return empty string if no buckets. Can be caused by EAGAIN. */
> > if (APR_BRIGADE_EMPTY(bb)) {
> > return PyString_FromString("");
> > }
> >
> > seems to fix the problem. Ie., use call to APR_BRIGADE_EMPTY(bb) to check
> > whether any new buckets added and returning empty string if not.
>
> Okay, this may work, but the EAGAIN propogating backup as an empty
> string to Python can cause a tight loop to occur where calls are going
> out and back into Python code. This will occur until something is read
> or an error occurs.
>
> To avoid the back and forth, another option may be:
>
> while (APR_BRIGADE_EMPTY(bb)) {
> Py_BEGIN_ALLOW_THREADS;
> rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ,
> bufsize);
> Py_END_ALLOW_THREADS;
>
> if (! APR_STATUS_IS_SUCCESS(rc)) {
> PyErr_SetObject(PyExc_IOError,
> PyString_FromString("Connection read error"));
> return NULL;
> }
> }
>
Graham,
this code runs smoothly, i.e. no segfaults, all tests passed:
FreeBSD 4.9:
Apache/2.0.50 (prefork) Python/2.3.4
Apache/2.0.55 (prefork) Python/2.4.2
Thanks!
