On Fri, 7 Apr 2000, Russell D. Weiss wrote:

> I'm using Apache::Session within a large Web application (consisting of many
> scripts).  We also have multiple developers on this project, some of whom
> are junior developers with only a bit of mod_perl experience.
> 
> In any case, I've written a custom session package that wraps to
> Apache::Session.  It uses Apache::Session for persistence, but it adds nice
> functionality to it (cookies, session time-out, etc.).
> 
> Normally, this works great.  No problem at all.  This object goes out of
> scope at the end of the script (it's scoped lexically with "my").  It also
> goes out of scope when "die" is explicitly called.  If I add "die 'Blah blah
> blah'" to an app, things are fun.  BUT... sometimes when there's a syntax
> error in the code, this object just stays in scope.  This causes a real
> problem, because then the developer will just re-load.  The process will sit
> there forever, waiting for the session lock to go away.  But it never
> does...

My advice would be to eliminate the syntax errors in your
code.  Apache::Session wasn't designed with the goal of working around
other people's erroneous code!

> 
> This is a problem.  Under certain strange circumstances, the object does not
> go out of scope.  Even under PerlRun (which I *thought* would clear the
> application's namespace at the end of execution), the object stays in scope
> (I print to STDERR in DESTROY to see this).

There are some bugs in Perl 5.005_03 which sometimes cause adverse
interactions between eval and die.  One symptom seems to be that lexical
objects become immortal.  This is pretty rare, though.

Can you try Perl 5.6?

> The mod_perl server starts going crazy spawning off new threads for each
> request, because current threads are busy.  I placed some limits on this in
> httpd.conf, but this is not really a solution.  The only solution is to
> restart the server... But there's gotta be a better way!
> 
> This has been plaguing us for a while, and I can't figure it out.  I was
> considering writing a $SIG{__DIE__} handler that would take this object out
> of scope, but I ran into other issues there.  Has anyone else run into this
> problem?

-jwb

Reply via email to