I haven't tried it but you could probably modify the code I posted to test
it.  With the statement handle after 120(?) loops of apparent memory leak
+1, there is a correction of -119.

Good luck.

Steve.
On 28 May 2015 05:00, "Duncan McEwan" <dun...@ecs.vuw.ac.nz> wrote:

> Apologies for butting in on this thread, but I saw the following response
> from Tim recently and it made me wonder ...
>
> On Tue, 26 May 2015 14:13:05 +0100 Tim Bunce <tim.bu...@pobox.com> wrote:
>
> > I've added this as a note:
> >
> >     Note that the ChildHandles array holds weak references and that 'from
> >     time to time' the old slots get freed up. This isn't a leak, it just
> >     appears to be if you're not familiar with the caching that DBI does
> >     internally. You can rest assured that if the DBI did have a real leak
> >     a) a great many people would be affected and b) it would get fixed
> very
> >     quickly.
> >
> > I think 'from time to time' is every 120 or so newly created child
> handles.
>
> A while ago we had a mysterious problem using DBI in an application that
> was
> written as a plugin for the foswiki platform.  Since our foswiki instance
> was
> running persistently under fcgid it was long-running and over time we'd
> see a
> gradual increase in the open connections it held to our mysql database
> server.  Eventually our server would reach it's maximum connection count
> and
> reject new connections.
>
> The most recent time I tried to debug this was over a year ago (March 2014)
> and there was a brief exchange of emails on this list with the subject "DBI
> Mysql Driver Handle Mysteriously Changes".
>
> Since then we've given up (!) and changed the way our application ran so it
> is no longer a foswiki plugin.  That seems to have "fixed" the connection
> leakage and so we are unlikely to ever go back to find out exactly what was
> going on here.
>
> But seeing this response from Tim about the fact that the DBI can cache up
> to
> 120 or so handles made me wonder if this is true for database handles as
> well
> as statement handles?  Is it possible that our "problem" was simply the
> correctly working DBI caching misbehaving due to our application running
> persistently in multiple fcgid processes.
>
> I'm not looking to re-open investigating this issue - our environement has
> now changed sufficiently that recreating the set up with the connection
> leak
> to do more debugging would be quite difficult.  But I was just curious
> about
> whether the above could be the case.  If the answer is "no" I'll be happy
> to
> just leave it at that!
>
> Thanks.
>
> Duncan
>

Reply via email to