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
Re: mutex dir?
Hmmm, somehow I managed to vapourise an email, didn't even get to my sent mail box. Let me try this again. Jim Gallacher wrote .. > Graham Dumpleton wrote: > > Correct, is actually done from the mod_python module init function. > > > > The only way one could have it dynamically changing is through an > > Apache -D option checked by using ap_exists_config_define(). > > This is incorrect. You can get at the directives from python_init. Proof > of concept patch attached. Apply the patch and add the following > directives in your apache config after the LoadModule. > > LoadModule python_module /usr/lib/apache2/modules/mod_python.so > PythonModuleConfig max_locks 911 > PythonModuleConfig mutex_dir /some/place/safe > > Check the error.log for the results. > > I'm sure I don't need to tell everyone that this is intend as Proof of > Concept only. Don't blame me if your hair catches on fire and your teeth > fall out as a result of using this patch. :) I don't have much hair left, so I better believe you. Thus I stand corrected. I also should look more closely at the code before I send off email. :-) If the settings are going to be a generic key/value like in PythonOption, but only for purposes of the mod_python system itself, maybe it should be called PythonSystemOption. Prefer PythonSystemOption as "Module" is too confusing to me given you have both Apache modules and Python modules and a module importer. Also wary of "Config" because of confusion with "req.get_config()". Other than that, probably is reasonable. What other configuration things are there like this that could be handled in the same way? Would it be possible using such a thing to specify a directory that could be prefixed to sys.path to say where mod_python Apache module should look for mod_python Python modules? It is always a pain to debug sometimes when people have multiple versions of Python and for various reasons their Apache environment means it is finding wrong mod_python modules. If had way of saying where it was, could override it as way of proving one way or another it is a problem. Yes/No? Graham
Re: Getting Started on mod_python 3.3.
Jim Gallacher wrote .. > Graham Dumpleton wrote: > > Is my list of suggested JIRA items then seen as being reasonable for > > such a projected release? > > This seems reasonable, since we have either already committed the fixes > or have patches available (I think). I don't have changes ready for MODPYTHON-113, having PythonImport use apache.import_module(). I am quite happy to drop that from the list as would need to be sure that one worked okay. Might also be a good idea to defer that anyway to also address MODPYTHON-117 and MODPYTHON-118 at the same time as changing code in same area. All the rest in my list we have code ready for. > > Do we want to create a new JIRA issue for the mutex directory issue and > > also include a fix for that, but limit it to just an option to configure > > to override the directory? > > I can live with that. I don't like the idea of adding alot of new > functionality into a bugfix release, but a configure option is a pretty > minor change. The configure option is probably still good to have even if later we decide to also allow it to be overridden in Apache configuration. Possibly doesn't help to solve any conflict issues with test suite though. > Jim > > > > Graham > > > > 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). > >> > >>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.
Graham Dumpleton wrote: Is my list of suggested JIRA items then seen as being reasonable for such a projected release? This seems reasonable, since we have either already committed the fixes or have patches available (I think). Do we want to create a new JIRA issue for the mutex directory issue and also include a fix for that, but limit it to just an option to configure to override the directory? I can live with that. I don't like the idea of adding alot of new functionality into a bugfix release, but a configure option is a pretty minor change. Jim Graham 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). 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: mutex dir?
Graham Dumpleton wrote:
Grisha wrote ..
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.
Correct, is actually done from the mod_python module init function.
The only way one could have it dynamically changing is through an
Apache -D option checked by using ap_exists_config_define().
This is incorrect. You can get at the directives from python_init. Proof
of concept patch attached. Apply the patch and add the following
directives in your apache config after the LoadModule.
LoadModule python_module /usr/lib/apache2/modules/mod_python.so
PythonModuleConfig max_locks 911
PythonModuleConfig mutex_dir /some/place/safe
Check the error.log for the results.
I'm sure I don't need to tell everyone that this is intend as Proof of
Concept only. Don't blame me if your hair catches on fire and your teeth
fall out as a result of using this patch. :)
Jim
Index: src/mod_python.c
===
--- src/mod_python.c(revision 377430)
+++ src/mod_python.c(working copy)
@@ -314,7 +314,25 @@
int max_clients;
int locks;
int n;
+
+/* PythonModuleConfig Proof of Concept */
+char *val;
+py_config *conf =
+(py_config *) ap_get_module_config(s->module_config,
+ &python_module);
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s,
+ "TEST init_mutexes: checking for values set by
PythonModuleConfig");
+
+val = apr_table_get(conf->directives, "max_locks");
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s,
+ "TEST init_mutexes: max_locks = %s", val);
+
+val = apr_table_get(conf->directives, "mutex_dir");
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s,
+ "TEST init_mutexes: mutex_dir = %s", val);
+/* end POC */
+
/* figre out maximum possible concurrent connections */
/* MAX_DAEMON_USED seems to account for MaxClients, as opposed to
MAX_DAEMONS, which is ServerLimit
@@ -1621,7 +1639,45 @@
return NULL;
}
+
/**
+ ** directive_PythonModuleConfig
+ **
+ * This function called whenever PythonModuleConfig directive
+ * is encountered.
+ *
+ * WARNING WARNING WARNING
+ * This is proof of concept code
+ * DO NOT USE IN PRODUCTION
+ */
+static const char *directive_PythonModuleConfig(cmd_parms *cmd, void *
mconfig,
+ const char *key, const char *val)
+{
+py_config *conf;
+conf = (py_config *) mconfig;
+if(val!=NULL) {
+apr_table_set(conf->options, key, val);
+
+conf = ap_get_module_config(cmd->server->module_config,
+&python_module);
+apr_table_set(conf->directives, key, val);
+}
+else {
+ /** We don't remove the value, but set it
+ to an empty string. There is no possibility
+ of colliding with an actual value, since
+ an entry string precisely means 'remove the value' */
+apr_table_set(conf->directives, key, "");
+
+conf = ap_get_module_config(cmd->server->module_config,
+&python_module);
+apr_table_set(conf->directives, key, "");
+}
+return NULL;
+}
+
+
+/**
** directive_PythonOptimize
**
* This function called whenever PythonOptimize directive
@@ -2131,6 +2187,9 @@
AP_INIT_TAKE12(
"PythonOutputFilter", directive_PythonOutputFilter, NULL,
RSRC_CONF|ACCESS_CONF,
"Python output filter."),
+AP_INIT_TAKE12(
+"PythonModuleConfig", directive_PythonModuleConfig, NULL, RSRC_CONF,
+"Python module configuration."),
{NULL}
};
Re: Getting Started on mod_python 3.3.
Is my list of suggested JIRA items then seen as being reasonable for such a projected release? Do we want to create a new JIRA issue for the mutex directory issue and also include a fix for that, but limit it to just an option to configure to override the directory? Graham 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). > > 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: mutex dir?
Grisha wrote .. > > 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. Correct, is actually done from the mod_python module init function. The only way one could have it dynamically changing is through an Apache -D option checked by using ap_exists_config_define(). Not too useful for general use, but may be necessary when running test suite to avoid clashes if it is that big a problem. Graham
Re: Getting Started on mod_python 3.3.
Grisha wrote .. > > 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. :-) Yes it is. Note that there is one caveat on this fix because of how simple GIL works when there are multiple interpreters. Namely, if using third party code which uses simple GIL API, then "PythonInterpreter" must be explicitly set to "main_interpreter" for context the code is used in. This interpreter is now gauranteed to be the first interpreter which was created, thus satisfying simple GIL requirements. No real drama, we just need to document this fact. Graham
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
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.
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.
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: 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: mutex dir?
tisdagen den 14 februari 2006 18.35 skrev Jim Gallacher: > Oden Eriksson wrote: > > tisdagen den 14 februari 2006 14.19 skrev Jim Gallacher: > >>Oden Eriksson wrote: > >>>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? > >> > >>I assume you mean as an option to configure, rather than as an Apache > >>configuration directive? > > > > I meant as an apache configuration directive. > > After giving this some thought I think it should be both, so the options > become: > > 1. Default /tmp > > 2. --configure --with-mutex-dir=/some/directory > Allows distributions to package mod_python according to their > platform specification, without the need for applying any patches. > > 3. PythonMutexDir /some/place > This would mainly be used in the unit tests to override the setting > applied by option #2. This avoids Oden's unit test problem which is > similar to the problem described in MODPYTHON-119, where the unit test > defaults may conflict with a mod_python instance running on the server. Looks good to me. Please make sure the test case will survive too. Currently the test case fails all over the place for me... Why don't you write the test cases so that you can use Apache-Test? > 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 > > Currently the number of mutex locks is set with ./configure > --with-max-locks Looks very good. I was planning to make an optional rpm build switch so that you could rebuild the src.rpm so that you could use any number there. Speaking of locks, I think this could be improved a bit so that you don't have to use ipc for example. History has shown ipc semaphore locks are not very stable on linux. > By the way Oden, are you the offical mod_python maintainer on Mandriva? Amongst many other packages (too many), yes. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
[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
[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
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-126) PythonHandler in directive sets req.hlist.directory to useless value.
[ http://issues.apache.org/jira/browse/MODPYTHON-126?page=comments#action_12366319 ] Graham Dumpleton commented on MODPYTHON-126: FWIW, I think I know how to fix the above so it works. This time I stumbled onto the fact that in Apache one can programmatically query back through the contexts of directives defined in a configuration. This will allow the code which deals with Python*Handler directives to query back looking for the Directory or DirectoryMatch directive it was used in. If it can't find either, then it would have been a Location directive and it now will know the URL should not be used as the handler directory. If it did find Directory, it could work out the argument to it and use that as the basis for working out the directory. Ie., it would skip past any File directives and go direct to the Directory context. The only trick to solve is the best way of dealing with wildcards or regexes for directory. One probably has to leave it until the very point that request is being handled, which means that Apache wildcard/regex matching routines may need to be exposed in mod_python Python APIs to ensure same matching scheme can be used against the req.filename member. Thus, my whole idea of being able to mark base directories as discussed on mailing list is no longer relevant to solving this particular issue. > PythonHandler in directive sets req.hlist.directory to useless value. > - > > Key: MODPYTHON-126 > URL: http://issues.apache.org/jira/browse/MODPYTHON-126 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Reporter: Graham Dumpleton > > When you have Apache ".htaccess" configuration like: > SetHandler mod_python > #PythonPath "['/Users/grahamd/Sites/auth']+sys.path" > > PythonHandler page1::handler_txt > > > PythonHandler page2::handler_txt > > and "page1.txt" is accessed, the req.hlist.directory attribute, which is > supposed to list the name of the directory the PythonHandler directive was > used in, gets set to "page1.txt/" instead. > This value then gets added into "sys.path". Because it doesn't actually > identify the directory, the module "page1" cannot actually be found when the > import is performed. > [Fri Feb 10 09:08:40 2006] [error] [client 127.0.0.1] PythonHandler > page1::handler_txt: Traceback (most recent call last): > [Fri Feb 10 09:08:40 2006] [error] [client 127.0.0.1] PythonHandler > page1::handler_txt: File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py", > line 288, in HandlerDispatch\nlog=debug) > [Fri Feb 10 09:08:40 2006] [error] [client 127.0.0.1] PythonHandler > page1::handler_txt: File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py", > line 508, in import_module\nf, p, d = imp.find_module(parts[i], path) > [Fri Feb 10 09:08:40 2006] [error] [client 127.0.0.1] PythonHandler > page1::handler_txt: ImportError: No module named page1 > The only workaround at this point is to explicitly define the PythonPath > directive to include the directory the modules and ".htaccess" file are in. > Not sure yet whether there is a way in Apache of determining the directory > the "Files" directive is used in and set "req.hlist.directory" correctly. -- 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
