Hi list,
I recently transferred our application to a more powerful server running
debian 3.1. As always I compiled the important parts (perl 5.8.7 without
threads and apache 1.3.34/mod_perl plus a lot of cpan modules) myself. Our
application (which uses Mason) ran fine for the last 3 years on all
On Thu, 2005-12-22 at 16:00 +0100, Tobias wrote:
> As soon as more than one parallel request is made I immediately get
> unexplainable DBI errors like "fetch() without execute()", "DBD driver
> has not implemented the AutoCommit attribute" or "Commands out of sync;
> you can't run this command now"
Zitat von Perrin Harkins <[EMAIL PROTECTED]>:
> On Thu, 2005-12-22 at 16:00 +0100, Tobias wrote:
> > As soon as more than one parallel request is made I immediately get
> > unexplainable DBI errors like "fetch() without execute()", "DBD driver
> > has not implemented the AutoCommit attribute" or "
On Thu, 2005-12-22 at 16:28 +0100, Tobias wrote:
> The weird thing is that I just rsync'd the code over from another debian
> system on which the application runs just fine. The only difference
> (as far as I can see) to the failing system is a debian Perl 5.8.4 (with
> threads) instead of a self-
Here is mybugreport:
-8<-- Start Bug Report 8<--
1. Problem Description:
[DESCRIBE THE PROBLEM HERE]
When running >make test
Get the following errror
[Thu Dec 22 09:28:15 2005] [info] base server + 27 vhosts ready to run tests
[Thu Dec 22 09:28:16 2005]
> Ideally we would run this in an event loop
Anyone is welcome to take over maintenance of http::server::singlethreaded
and add apache/mp features to it, then there would be big monolithic
perl web-servers. Blocking in the request handlers would remain a problem,
but not anything that couldn't be
Hi,
Is this still supposed to work in TransHandler with Apache 2.2 ?
sub handler {
my $r = shift;
my $uri = $r->uri;
$r->filename("proxy:http://test:4949".$uri);
$r->handler('proxy-server');
$r->proxyreq(1);
return Apache2::Const::
On Thu, 2005-12-22 at 12:22 -0600, David Nicol wrote:
> To make a 3TAM system work like mod_perl, never mind the hooks
> into the various apache request service stages, every long-running
> perl script could be interpreted into one of serveral mp_like interpreters
> at the handler layer, or even ev
On Dec 22, 2005, at 1:51 PM, Perrin Harkins wrote:
You're pretty much describing lighthttpd + FastCGI. However, I don't
think it supports SSL and it obviously has no support for any other
apache modules or for hooking into request stages (although FastCGI
has
some things, like authenticatio
CHANGES
- Fixed param() to allow for blessed hash-refs. [Alex Kapranoff]
- Fixed url-escaping to work with UTF-8 characters. [Alex Kapranoff]
- Added support for JS escaping. [Alex Kapranoff]
- Fixed a compatibility problem with HTML::Template v2.8, which
is now a prerequisite.
DE
Kent, Mr. John (Contractor) wrote:
Here is mybugreport:
-8<-- Start Bug Report 8<--
1. Problem Description:
[DESCRIBE THE PROBLEM HERE]
When running >make test
Get the following errror
[Thu Dec 22 09:28:15 2005] [info] base server + 27 vhosts ready to
On 12/19/05, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > Is there a way to configure mod_perl to act more like mod_php in that
> > each request gets a "fresh" interpreter to work in?
>
> Just set MaxRquestsPerChild to 1. However, most shared hosts actually
> run PHP as CGI.
Erm.. Spawning a who
On Dec 22, 2005, at 11:44 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
wrote:
Also don't most shared hosts use mod_php, not PHP/CGI? What would be
the point of PHP via CGI? mod_php works just fine. (As long as you
stay away from threads.)
security.
(sorry, this is off topic, but its a re
On 12/23/05, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>
> On Dec 22, 2005, at 11:44 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> wrote:
>
> > Also don't most shared hosts use mod_php, not PHP/CGI? What would be
> > the point of PHP via CGI? mod_php works just fine. (As long as you
> > stay aw
14 matches
Mail list logo
