[mod_python] mod_python executing old versions of my code

Martin MOKREJŠ mmokrejs at ribosome.natur.cuni.cz
Wed Jan 25 16:51:17 EST 2006


Hi Graham,
  my answer goes now through the list, so others can learn also on
my issue ...

Graham Dumpleton wrote:
> Martin MOKREJS wrote ..
>>Graham Dumpleton wrote:
>>>Someone on the mod_python list wrote:
>>>>But I can find no way to force testmodule to be re-imported. What am
>>I doing wrong?
>>>
>>>You are not doing anything wrong, the current system simply doesn't
>>>work very well.
>>>
>>>The best you can get is to use:
>>>
>>>  from mod_python import apache
>>>  import os
>>>
>>>  __here__ = os.path.dirname(__file__)
>>>  
>>>  def handler(req):
>>>       req.write("Hello World!")
>>>       testmodule = apache.import_module("testmodule,path=[__here__])
>>>       testmodule.foo(req)
>>>       return apache.OK
>>>
>>>This uses apache.import_module() on each request to import the module.
>>>In practice though, if the file has not changed it just uses what is
>>>already in the cache. If it has changed, you should then see the change.
>>>
>>>You can't use apache.import_module() at global scope in the module and
>>>get the same effect as that only gets executed when main.py is imported.
>>>Thus you don't get the check for changes to testmodule.py on every
>>>request.
>>>
>>>I have a completely rewritten module importing system for mod_python
>>>which addresses nearly all the issues it has. I will be making it available
>>>for trialing after mod_python 3.2.6 is officially released. It will require
>>>though having 3.2.6, which means it will be useless to you with 2.7.11.
>>
>>I still see problems with module import using 3.2.6 on linux, compiled
>>today. I am using typically something like:
>>
>>try:
>>    from mod_python import apache
>>
>>    _directory = os.path.dirname(__file__)
>>    for _my_modulename in ['web_settings', 'web_header', 'web_menu', 'web_text_frame',
>>                           'web_footer', 'sql_io', 'helper_functions', 'globals']:
>>        __dict__[_my_modulename] = apache.import_module(_my_modulename,
>>                                                        log=1, path=[_directory])
>>except: # without raise
>>    import web_settings
>>    import web_header
>>    import web_menu
>>    import web_text_frame # calls mysql_python driver
>>    import web_footer
>>    import sql_io
>>    import helper_functions
>>    import globals
>>
>>
>>So, should I wait or adjust my code?
> 
> 
> What sort of problems?

For example, when changing a variable in the top-level of imported globals file,
the change of the value is not reflected by apache until I restart it.


> Note though that the more major problems with apache.import_module()
> aren't fixed in 3.2.6.

I see. Thanks! I know that would duplicate the JIRA bug-tracking system a bit,
but maybe a brief overview of the hottest bugs should be mentione din the README
or better, BUGS file. I think there was already a discussion on this once. ;)


> You should find that mod_python.publisher may work a bit better in 3.2.6
> as it uses a separate module importer. If you use apache.import_module()
> inside of mod_python.publisher code, you could end up with a whole new

I think I do use mod_python publisher. ;)

# main.py with the above try/except wrapped import stuff, those therein imported
#         modules use the same try/except logic
#
def index(req):
   ... # does some stuff
    return _some_string


> bunch of problems if a module is imported by both mod_python.publisher
> and apache.import_module(). Specifically that there will be two distinct
> copies of the module. I pointed out the problems that the changes to the
> mod_python.publisher module importer would cause in this situation, but
> the changes were still made. I would have preferred to have seen the use
> of apache.import_module() by mod_python.publisher be left alone until
> apache.import_module() was fixed. Ie., better known problems than a whole
> class of new ones. :-(

OK, I used to have simple:

import foo
import bar

but some months ago I was advised to use the apache.import_module approach
when running under mod_python and the usual imports keep just for direct python
execution. Should I revert back (and rip away the try/excpet stuff)?
No problem, but maybe time to keep in the README section with recommended
examples for this and that version or apache2, mod_python, etc. :(


>>>Whether this new module importing system gets adopted is another
>>>matter entirely though. Some have argued in the past that the current
>>>arrangement is adequate even though it has known problems. ;-(
>>
>>No, the apache stop/start sucks, the restart approach doesn't work as the
>>init.d scripts on gentoo fail to wait for apache to shutdown completely ...
>>they start to startup somehow immediately, recognize apache is still up,
>>die but leave the lockfiles in. I have to start apache in several
>>start/start attempts to get it started actually.
> 
> 
> Apache child processes not terminating promptly may be because of:
> 
>   http://issues.apache.org/jira/browse/MODPYTHON-109
> 
> this is not addressed in 3.2.6 anf needs a bit more research first to see
> if the simple solution will not cause other issues. At this stage the only
> known issue is that not calling Py_Finalize() will mean that code registered
> using Python wrapper for atexit() will not be called. Have to check properly
> yet though whether code registered with apache.register_cleanup() and
> req.server.register_cleanup() will still be executed.

Well, if I can adjust my code to have the automatic reloading working again,
I don't care much about the apache issue. ;)

Thank you for all your effort.

martin


More information about the Mod_python mailing list