Hi Tim,
Thanks for the quick response.
> Could you post the fcgid configuration details for us?
> https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Our full httpd config is long and complex and not very pretty! I've extracted
out what I think are the bits from it that are associated with making foswiki
run under fcgid and attached them below.
> > The database connection used by this application should be persistent
> > due to the application calling DBI->connect_cached() on each invocation.
>
> Persistent within a single backend process, yes.
Yes, that's right. Our apache fires off a number of fcgid handlers, each
one running a persistent instance of the foswiki perl code. Our application
is in turn written as a foswiki "plugin". So in theory, each fcgid/foswiki
instance (process) should have a single persistent database connection
(the database, host, password and attributes are always the same) which gets
used when required to answer any queries that Apache passes to it.
> > I've got 1000's of lines of debugging showing this happening. Some of it
> > is my own, inserted as print statements or cluck calls directly into DBI.pm
> > and some of it the standard DBI debugging set to level 9. There is way too
> > much to include in this message, but I've included some small extracts below
> > to illustrate what I am seeing.
>
> What you've included doesn't show the drh changing.
Then maybe I'm mis-interpreting the debugging I'm seeing? The log extract
I posted contained:
DBI::dr=HASH(0x7f7fe874fee8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI
1.630-ithread (pid 18887)
...
DBI::dr=HASH(0x7f7fe874fee8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI
1.630-ithread (pid 18887)
...
<lots of repetitions of the above>
...
DBI::dr=HASH(0x7f7fe299c5e8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI
1.630-ithread (pid 18887)
The last DBI::dr=HASH(...) had a different value than the preceding ones.
> I suggest you focus on that. Specifically the code path taken by the
> request that notices that the drh has changed, _and_ the code path taken
> by the _previous_ request _in the same process_.
Yes. I had been looking at that. Within DBI.pm I've inserted calls to
cluck so I could see the stack trace both the case when a cached database
handle is returned and when a new one is created. There were *sometimes*
differences in the call stack between those times, but sometimes not.
At the moment I only turn DBI tracing on in the connect_cached() call and
turn it off again before the call returns. I did that because I was worried
about the amount of output that would be produced if I left tracing on.
But perhaps that is what I will have to do.
A potential further complication that I didn't mention previously is that
our application (which I *did* mention is written as a foswiki plugin)
uses the CGI::Application perl package. From a very quick look at its
code, it does seem to know about the DBI and could perhaps be doing something
"too clever" which is causing us problems. I'll look more into that as
well.
> > I don't know enough about perl internals to know exactly what this does.
> > But I did wonder if something like the following might be better given the
> > persistent nature of our application provided by fcgid.
> >
> > my $dbi = new DBI;
> > my $dbh = $dbi->connect_cached(...)
>
> No. Using new DBI (or DBI->new) isn't a valid way to use the DBI.
> Just DBI->connect_cached is fine.
OK - thanks for clarifying that and ruling it out as the source of the problem,
Duncan
Alias /foswiki/bin/configure /vol/ecs/lib/foswiki/bin/configure
Alias /foswiki/bin/viewauth /vol/ecs/lib/foswiki/bin/viewauth
Alias /foswiki/bin/viewfileauth /vol/ecs/lib/foswiki/bin/viewfileauth
Alias /foswiki/bin/viewfilemp4 /vol/ecs/lib/foswiki/bin/viewfile
Alias /foswiki/bin /vol/ecs/lib/foswiki/bin/foswiki.fcgi
# fcgid settings
FcgidMinProcessesPerClass 3
FcgidMaxProcessesPerClass 30
FcgidMaxRequestLen 104857600
FcgidIOTimeout 180
...
<Directory "/vol/ecs/lib/foswiki/pub">
Options None
AuthMCSFileChecks off
Satisfy Any
</Directory>
# This specifies the options on the Foswiki scripts directory. The ExecCGI
# and SetHandler tell apache that it contains scripts. "Allow from all"
# lets any IP address access this URL.
# Note: If you use SELinux, you also have to "Allow httpd cgi support" in your
SELinux policies
<Directory "/vol/ecs/lib/foswiki/bin">
AllowOverride None
Order Allow,Deny
Allow from all
Deny from env=blockAccess
Options +ExecCGI -FollowSymLinks
SetHandler cgi-script
# Limit access to configure to specific IP address(es) and user(s).
# Make sure configure is not open to the general public.
# It exposes system details that can help attackers.
# cf. http://foswiki.org/Support/ProtectingYourConfiguration for details.
<FilesMatch "^(configure)$">
SetHandler cgi-script
Order Deny,Allow
Deny from all
Allow from XX.XX.XX.XX
require group XXXXXX
</FilesMatch>
# When using Apache type login the following defines the Foswiki scripts
# that makes Apache ask the browser to authenticate. It is correct that
# scripts such as view are not authenticated.
<FilesMatch
"(attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
Require valid-user
</FilesMatch>
<Files foswiki.fcgi>
SetHandler fcgid-script
</Files>
</Directory>
