[pmwiki-users] PmWiki seems to "hang" on overloaded boxes

[Patrick R. Michaud]

On Sun, May 22, 2005 at 04:38:11PM +0200, Joachim Durchholz wrote:
> Radu wrote:
> >At 08:11 AM 5/22/2005, Joachim Durchholz wrote:
> >>Here's what happened: PmWiki suddenly started to "hang", i.e. it
> >>would not respond at all, or display only part of the output and
> >>"hang". With "hang", I mean that the browser still has the
> >>data-is-forthcoming animation, but no new data ever arrives. (For
> >>an "forever" value of one or two minutes.)

First and most importantly, what version of PmWiki?  

Second, note that by the time PmWiki is outputting information to
the browser, PmWiki has pretty much completed any "real work" that needs
to be done and is simply doing lots of print statements.  (Exception:
<!--wiki:--> and <!--function:--> items in the template are processed
as the page is being output.  However, the main content is processed
before *any* output takes place.)

So, if the browser has received some output but then hangs, it's
almost certainly something completely outside of PmWiki's control,
because PmWiki is just generating print statements.

> >Um. Have you tried deleting the .flock file? If after the one or two
> > minutes you actually do get the page, this is not the issue.
> 
> Well, once PmWiki hanged, calling up the site in another browser window
> would stall as well, and deleting .flock would fix that.

This seems to tell me you're running version of PmWiki older than
beta30.  In beta30 and later, the .flock file isn't used at all when
viewing pages -- only when editing them or changing page attributes.  
Are you seeing this problem in beta30 or later?

> To make it a bit clearer: I don't mind if PmWiki fails under overload -
> it has every right to do so. What I don't like is its failure mode: no
> error message, but a browser that keeps waiting for data that never
> comes, and a dysfunctional site (.flock-induced, though I don't know
> whether that's because the stalled PmWiki call never got around to
> cleaning out .flock or due to some other reason).

I ran into similar problems such as this in the distant past, and
I finally traced the problem to Apache.  When a browser closed a 
connection before output was completed (or even begun), Apache would
sometimes block indefinitely, never returning control back to PmWiki
nor killing off the PmWiki process.  Of course, there's pretty much nothing
that PmWiki can do about this -- if PmWiki never regains control after
executing a "print" statement, then PmWiki can't really report an error
or diagnostic or anything useful such as that.

In versions of PmWiki prior to beta30 that used .flock on every request, 
this was sometimes a real problem because a hung Apache/PmWiki process 
would maintain the lock on .flock and prevent other PmWiki processes from
progressing.  Newer versions shouldn't have this problem.  (OTOH, PmWiki
worked fine for years on many sites without ever displaying the problem,
so it seems to be Apache-configuration specific.)

Pm