mutex dir?
Hello. In our package in Mandriva I patch mod_python.c so that the mutex stuff is put in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7 plus fixes from the trunk and running the test suite it complains it cannot access /var/cache/httpd/mod_python/ (of course). So my question/request is, could you please make this directory set in the config? -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
[jira] Commented: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=comments#action_12366331 ] Sebastjan Trepca commented on MODPYTHON-111: OK, I understand and agree with your but then someone should change the documentation because now it says: A session will timeout if it has not been accessed for more than timeout, which defaults to 30 minutes. An attempt to load an expired session will result in a ``new'' session. From this line I thought accessing the session means that I execute the load() method, but I was apparantly wrong and spent few hours debugging my application and then few hours more for debugging mod_python. Can someone then please edit that line in docs and be more explicit about what that accessing means so people won't be confused when session will suddenly expire? Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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] Updated: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Sebastjan Trepca updated MODPYTHON-111: --- Component: documentation Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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: mutex dir?
On Tue, 14 Feb 2006, Jim Gallacher wrote: I wonder if we should generalize this, so rather than PythonMutexDir, we have PythonModuleConfig. Usage might look like: PythonModuleConfig mutex_dir /path/to/mutexs PythonModuleConfig max_mutex_locks 8 I may be wrong, but I think the reason this was never configurable was because the mutex is created before the apache config is read. Grisha
Re: Getting Started on mod_python 3.3.
Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now). Regards, Nicolas 2006/2/14, Nicolas Lehuen [EMAIL PROTECTED]: 2006/2/14, Graham Dumpleton [EMAIL PROTECTED]: [...] If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. MODPYTHON-78 Apache 2.2 patches. MODPYTHON-94 Support for optional mod_ssl functions on request object. MODPYTHON-113 Make PythonImport use apache.import_module() via CallBack method. MODPYTHON-119 DBM Session test patches. MODPYTHON-122 Bash 3.1.X configure patches. I know that MODPYTHON-94 isn't a bug fix, but a few people have been after this one. Also MODPYTHON-113 may not seem important, but will mean that any test package I make available for new importer will work properly in all cases where module imports occur. Anyway, after trolling through JIRA, these seemed to be the important ones to me, but other might have other suggestions. Now, the question is how we manage this. Do we concentrate on these only in the trunk and get them out of the way first as a 3.2.X release, holding back any changes to test framework? Or do we merge such changes from trunk on a case by case basis in 3.2.X branch? Graham I was thinking about working on the new test framework in parallel of real work, away from the trunk (in my /branches/nlehuen directory). I don't think it will be too hard to track down the changes in the trunk tests and bring them back in the new test framework, but I may be wrong. One the new tests are available, I'll merge them back in the trunk. So I guess it's not necessary to hold back the next release do to the tests, and it may be a good exercise to due a few 3.2.x releases in a short period of time before doing the 3.3.x release. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
2006/2/14, Nicolas Lehuen [EMAIL PROTECTED]: Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now). Regards, Nicolas Doh ! I've found the source code for Win32. I'll try to build it ASAP and give mod_python a try. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
Nicolas Lehuen wrote: Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now). I'm not sure we need *alot* of testing on *nix. The APR_STATUS_IS_SUCCESS macro is not an issue there, since it is defined as (rc == APR_SUCCESS), which is the change we've made anyway. That macro does have a different definition on Win32, so that's where the testing needs to happen. But if there is no Apache 2.2 for Win32, where does that leave us wrt to a release? After Graham's digging and the comments from Justin I'm much less concerned about a potential problem on Win32. I don't think we should pile a large number of changes in any given 3.2.x bugfix release. If each release has not deviated too much from the previous version, then we'll need to do less testing and can release more frequently. I'd hate to see us wait 2 or 3 months for 3.2.8 and find we have so many bug fixes, and little feature additions that we then need to go through another 3.2.8 beta cycle. Release early and release often. Jim Regards, Nicolas 2006/2/14, Nicolas Lehuen [EMAIL PROTECTED]: 2006/2/14, Graham Dumpleton [EMAIL PROTECTED]: [...] If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. MODPYTHON-78 Apache 2.2 patches. MODPYTHON-94 Support for optional mod_ssl functions on request object. MODPYTHON-113 Make PythonImport use apache.import_module() via CallBack method. MODPYTHON-119 DBM Session test patches. MODPYTHON-122 Bash 3.1.X configure patches. I know that MODPYTHON-94 isn't a bug fix, but a few people have been after this one. Also MODPYTHON-113 may not seem important, but will mean that any test package I make available for new importer will work properly in all cases where module imports occur. Anyway, after trolling through JIRA, these seemed to be the important ones to me, but other might have other suggestions. Now, the question is how we manage this. Do we concentrate on these only in the trunk and get them out of the way first as a 3.2.X release, holding back any changes to test framework? Or do we merge such changes from trunk on a case by case basis in 3.2.X branch? Graham I was thinking about working on the new test framework in parallel of real work, away from the trunk (in my /branches/nlehuen directory). I don't think it will be too hard to track down the changes in the trunk tests and bring them back in the new test framework, but I may be wrong. One the new tests are available, I'll merge them back in the trunk. So I guess it's not necessary to hold back the next release do to the tests, and it may be a good exercise to due a few 3.2.x releases in a short period of time before doing the 3.3.x release. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
On Tue, 14 Feb 2006, Nicolas Lehuen wrote: 2006/2/14, Graham Dumpleton [EMAIL PROTECTED]: [...] If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. If this is the one where you get Restriction Execution errors upon launching a thread, then I'm kinda keen on seeing this fixed sooner than later. Just my $0.02. :-) Grisha
Testing mod_python SVN trunk with Apache 2.2 on Win32
Hi, I've built Apache 2.2 and tested mod_python SVN trunk with it. The two register_cleanup tests fail. Apparently it's because the test code registers a cleanup function giving the current request as parameter. Of course when the cleanup function is called, the request object is no longer valid, and Apache segfaults. Fixing this is only a matter of fixing the test code, yet I wonder how this code could properly run on Apache 2.0.55. Maybe the request object was not properly destroyed and this has been fixed in Apache 2.2 ? This also shows that we should document the fact that the current request object should not be passed directly or indirectly to the *.register_cleanup functions. Maybe we could implement a little test in those function to make sure it is not passed directly ? Those two failures aside, the rest of the tests are OK. Regards, Nicolas
