Received: (qmail 49626 invoked by uid 501); 20 Jun 2000 16:49:41 -0000
Message-Id: <20000620164941.49625.qmail@locus.apache.org>
Date: 20 Jun 2000 16:49:41 -0000
From: Wes Hardaker <wjhardaker@ucdavis.edu>
Reply-To: wjhardaker@ucdavis.edu
To: submit@bugz.apache.org
Subject: perlAccessHandler locks all other requests
X-Send-Pr-Version: 3.110

>Number:         6215
>Category:       mod_perl
>Synopsis:       perlAccessHandler locks all other requests
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Jun 20 09:50:00 PDT 2000
>Closed-Date:    Tue Dec 12 20:30:00 PST 2000
>Last-Modified:  Tue Dec 12 20:30:00 PST 2000
>Originator:     wjhardaker@ucdavis.edu
>Release:        3.1.12
>Organization:
>Environment:
win32 binary install of apache (or from source).  mod_perl 1.21 (binary or source).
OS: NT4 (sp4 on one machine, probly
>Description:
Internally to our environment, we have a mod_perl based access handler the details of which aren't important.

With apache 3.1.12 (3.1.9 didn't exhibit the problem) when the access handler is enabled the web server does not process other incoming requests until the first is finished downloading the file in question.  This is extremely bad if you're trying to server some very large files protected by an access handler, as all future clients aren't able to see anything (files, html, etc) beyond the access handler until the first request has either fully downloaded the file in question or they've hit cancel.

Even a really simple access handler:

sub handler {
return OK;
}

exhibits this behavior.
>How-To-Repeat:
See full description.

PerlModule access.pm
<Location /blah>
PerlAccessHandler access
</Location>

access.pm:
package accesss;
use Apache::Constants qw(OK);

sub handler {
  return OK;
}

put a large file in blah and start downloading it, and then in another window try to download any other file in blah before the large file download finishes.
>Fix:
I wish.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open-feedback
State-Changed-By: wrowe
State-Changed-When: Tue Jun 20 11:55:00 PDT 2000
State-Changed-Why:

If you eliminate mod_perl, and use perl as a seperate cgi
process, do you still observe this behavior?

I'm asking because I believe that mod_perl isn't interacting
well with the threaded Win32 Apache model.

Please try a cgi as a handler, rather than linking in
mod_perl, and indicate if the issue disappears.  If so,
I would expect we will look at mod_perl for the 2.0 release
to address this behavior.


State-Changed-From-To: feedback-closed
State-Changed-By: wrowe
State-Changed-When: Tue Dec 12 20:29:58 PST 2000
State-Changed-Why:
[This is a standard response.]
No response from submitter, assuming issue has been resolved.
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]