I have a Perl daemon which gets this error once very couple of hours under
stress testing -- 5 daemons, 20 clients, with the load factor wandering around
between 10 and 20. This is Centos 6.2 and DBI 1.616.
'prepare_cached(select x1, x2, x3 from x where x.id = ?) statement handle
DBI::st=HASH(0xf5e2ea0) still Active at xxx.pm Line 2072
The daemon disconnects before forking, reconnects afterwards.. There is a
metric ton of wrappers, of course, so posting the actual code is not very
useful.
It's always the same code and the same caller. The code is used all over the
place in our system, called millions of times every day.
The warning appears harmless, both from not seeing any other errors and from
the documentation on default behavior. As I said, there's a ton of code
exercising the wrapper modules. I see from googling that the usual cause is
knowing there are some number of rows, fetching one row at a time, but not
fetching the EOF row or not calling $sth->finish. I cannot see taht as teh
problem here, since so much code uses that same code in hundreds of programs
invoked millions of times per day.
It occurred to me to wonder about the global cache used by prepare_cached().
Is it possible that it isn't cleared by the disconnect, and somehow carries
across the fork?
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / fe...@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
