On Wed, Jun 17, 2015 at 4:41 PM, Alessandro Molina < [email protected]> wrote:
> In case you have issues with C modules, it might often help to set an high > number of processes and use a single thread for each one of them. > I still suspect that your problems are caused by pyodbc by the way > Just want to start out with saying i can't thank you enough for taking time to help me work through this! I am using mxodbc(commercial product) but your point stands and i 100% agree. If you leave off the processes=X declaration from mod_wsgi config, does it just let apache manage how many processes to spawn? Looking at processes running i see 5 /usr/sbin/apache2 running which (unless i am missing something) means apache has 5 processes running using 1 thread but i am kind of guessing. The systems piece of this is not my strong point. I did read over this earlier today and based on what i read it shouldn't be the issues but the segfault occurs during the odbc calls. 15.1 Running mxODBC from a CGI script <https://www.egenix.com/products/python/mxODBC/doc/#_Toc413883775> ODBC drivers and managers are usually compiled as a shared library. When running CGI scripts most HTTP daemons (or web servers) don't pass through the path for the dynamic loader (e.g. LD_LIBRARY_PATH) to the script, thus importing the mxODBC C extension will fail with unresolved symbols because the loader doesn't find the ODBC driver/manager's libs. To have the loader find the path to those shared libs you can either wrap the Python script with a shell script that sets the path according to your system configuration or tell the HTTP daemon to set or pass these through (see the daemon's documentation for information on how to do this; for Apache the directives are named SetEnvandPassEnv). On Windows, you also have to take into account that the ODBC data sources defined in the ODBC manager are usually restricted to specific user accounts. You can work around this by either setting up the ODBC data sources for the web server service account or by configuring the data as system data sources. 15.2 Running mxODBC with mod_wsgi <https://www.egenix.com/products/python/mxODBC/doc/#_Toc413883776> Using mxODBC with *mod_wsgi* <http://code.google.com/p/modwsgi/> is generally possible. However, since the script will run under a restricted user account, some care has to be taken to make the setup work. Please see 15.1Running mxODBC from a CGI script for more details on getting ODBC drivers to work in such an environment. mod_wsgi and Python 2.7 <https://www.egenix.com/products/python/mxODBC/doc/#_Toc413883777> On Windows, there is also another issue to consider when running the combination Apache, mod_wsgi and Python 2.7. Due to changes in Python 2.7, manifests for the Visual C++ runtime environment, needed by Windows to find the right DLL to load, are no longer added to Python extensions, since this caused problems with loading them into Python processes (see *Python Issue 4120* <http://bugs.python.org/issue4120>). Unfortunately, neither mod_wsgi nor Apache appear to include the required manifests either. This causes an import error when trying to load mxODBC into a mod_wsgi run process, since Windows cannot resolve the DLL references in mxODBC without the manifest. Since this affects not only mxODBC, but other Python C extensions as well, you may want to use a work-around until either Apache or the mod_wsgi team solves the problem: Manifest work-around <https://www.egenix.com/products/python/mxODBC/doc/#_Toc413883778> Adding the VC++ manifests to the Apache process is explained in *this posting* <http://groups.google.com/group/modwsgi/msg/afb025dc949c7051>. You will also have to install the *MS VC++ 2008 CRT SP1 redistributable package* <http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en> on the server running Apache. With those changes in place, mxODBC should load without problems. Paul Kraus IT Director / Project Management Director (216) 916.9801 Direct Dial (216) 267.6176 Fax www.pelsupply.com -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/turbogears. For more options, visit https://groups.google.com/d/optout.
