RE: [QUESTION] Browser hangs if multiple requests on the same Perlresource (Apache2, modperl2, Win32)
Thanks a million, Stas. So it looks that this is either a problem on my config parameters, or maybe that the problem occurs only when running on *Windows* (I'm running Apache2 and modperl2 on WinXP)... Any hint about what could break in this specific situation ? Or known issues with Apache2+modperl2 on this platform which is not documented in the current FAQ and troubleshooting docs of modperl? Thanks again, Pascal.
Apache2::Cookie - can't find cookie_clas.al
Hi, I'm running the latest version of mod_perl and libapreq (from subversion - all tests pass). I getting an error from Apache2::Cookie when I try to create an Apache2::Cookie::Jar. The Error Message: Can't locate auto/Apache2/Cookie/Jar/cookie_clas.al in @INC (@INC contains: /home/wyllie/dev/Alta/blib/lib /home/wyllie/dev/Alta/blib/arch /d/fish/web/modules/Alta/t /home/wyllie/dev/Alta/t /usr/local/perl-5.8.6/lib/x86_64-linux /usr/local/perl-5.8.6/lib /usr/local/perl-5.8.6/lib/site_perl/x86_64-linux /usr/local/perl-5.8.6/lib/site_perl .) at /usr/local/perl-5.8.6/lib/site_perl/x86_64-linux/Apache2/Cookie.pm line 109 The code which causes the error: my $jar = Apache2::Cookie::Jar->new( $r, VALUE_CLASS => "Alta::Cookies::Cookie" ); I have tried looking through the tests for libapreq, but I could not find a reference to Apache2::Cookie::Jar. I would appreciate any and all suggestions Thanks! Andrew
Re: [ANNOUNCE] mod_perl 2.0.0 (preview!)
On 5/14/05, Philippe M. Chiasson <[EMAIL PROTECTED]> wrote:
> #* Allright folks, RC6 was released a while ago, and various issues
> were resolved. According to our planned schedule, I am releasing
> a mod_perl-2.0.0 preview! As before, this is your last chance to
> affect the new API, since after 2.0.0 is released, incompatible API
> changes will not happen. So, one more time, test this tarball as much
> as possible. If all is well, this could become the official 2.0.0 release. *#
>
> Again, thank you for all the testing and the bug reports!
>
> Get it while it's hot:
>
>file: http://people.apache.org/~gozer/mp2/mod_perl-2.0.0-dev.tar.gz
>size: 1434124 bytes
> md5: c6d24621b1aed5cec7028e8595eecccb
>sha1: effe5b0de76c2a9a34ee36e3265cf4b498e98444
> gpg: http://people.apache.org/~gozer/mp2/mod_perl-2.0.0-dev.tar.gz.asc
> rev: 170139
>
> Changes since RC6:
>
> fix the ap_install target in the top-level Makefile (used for static
> build) [Stas]
>
> Reintroduce a pure-Perl version of ModPerl::Util::unload_package()
> The problematic XS version is now called unload_package_xs() and
> not used by default [Gozer]
>
> More APR::Status wrappers: [Stas, Randy Kobes]
> - is_EOF
> - is_ECONNABORTED
> - is_ECONNRESET
> - is_TIMEUP
>
> make sure that the build picks up the include directories based on the
> apxs queries and only search the httpd source if $self->{MP_AP_PREFIX}
> was set. Earlier it was always picking the headers from the httpd
> source if it was available, which was resulting in the wrong headers
> if the installed httpd was different than the source that was found
> [Stas]
>
> introduce ModPerl::RegistryPrefork and ModPerl::PerlRunPrefork, which
> behave the same as ModPerl::Registry and ModPerl::PerlRun,
> respectively, but chdir to the script's directory like mod_cgi
> does. These two new handlers will refuse to load under threaded MPMs
> where chdir can't be used as it will affect all running threads [Stas]
>
> ModPerl::RegistryCooker::chdir_file_normal() now chdirs to the current
> script's directory or the specified directory as an argument, as it
> was planned in first place. Therefore switch ModPerl::Registry and
> ModPerl::PerlRun to us NOP for this method call. If chdir_file is
> mapped to chdir_file_normal(), then run() and
> convert_script_to_compiled_handler() now call chdir to the script's
> directory and at before returning go back to the server root. [Stas]
>
> prevent undef warnings in catfile() calls in Apache2::Build when
> called from the ModPerl-Registry tree [Stas]
>
> fix modperl_brigade_dump to use apr_file_printf() instead of
> fprintf(), which doesn't work everywhere [Stas]
>
> Fix a warning triggered by `ln` on Cygwin, when running perl
> Makefile.PL for a second time without previously running make
> clean. [Nick *** <[EMAIL PROTECTED]>]
>
> When compiling a static mod_perl and
> MP_AP_CONFIGURE="--with-apr=/some/path" argument is given, Apache will
> use the apr-config at the given path, but mod_perl was using the
> default at "srclib/apr/.libs". Fix that [Nick *** <[EMAIL PROTECTED]>]
>
> Show MP_APU_CONFIG as an argument to Makefile.PL in the Usage
> menu. [Nick *** <[EMAIL PROTECTED]>]
>
> Makefile.PL: fix the pre-rename mp2 install diagnostics code, to use
> the mp version of 1.999xx and not 1.999_xx, as the latter is
> unsuitable for numerical comparison, also fix the name of the reported
> conflicting directory [Stas].
>
> add APR::Status::is_(EACCES|ENOENT), and use in ModPerl::RegistryCooker
> to return, as appropriate, Apache2::Const::(FORBIDDEN|NOT_FOUND),
> based on [EMAIL PROTECTED] Also remove a check in modperl_slurp_filename
> of src/modules/perl/modperl_util.c to enable $@ to be set when
> opening or reading a file fails. This fixes a bug on Win32, revealed
> in 404.t and redirect.t of the ModPerl-Registry tests, as reported
> by Steve Hay and Markus Wichitill [Stas, Randy Kobes]
>
> link Apache2::* and ModPerl::* to mod_perl.a and DynaLoader.a, but
> -lmod_perl and -lDynaLoader don't work, and we can't supply the full
> paths, because MakeMaker doesn't allow this. I workaround this by
> making a symlink to mod_perl.a (called libmod_perl.a) and copy
> DynaLoader.a to libDynaLoader.a (I don't create a symlink, because,
> when running make clean, the real DynaLoader.a may get deleted). The
> APR::* extensions are not affected, because in both cases we link them
> against aprext. Also other small fixes are added. [Nick ***
> <[EMAIL PROTECTED]>]
>
> --
>
>
>
why is not announced on perl.apache.org ?
thanks
Leonel
Re: Baffling unicode wierdness
On 5/19/05, Randy Kobes <[EMAIL PROTECTED]> wrote:
> On Wed, 18 May 2005, Jay Savage wrote:
>
> > On 5/18/05, angie ahl <[EMAIL PROTECTED]> wrote:
> > > I can confirm that it's happening before the data's gone
> > > to the database or anything. I'm getting the params from
> > > CGI.pm and then decoding via decode("utf8", $v) The page
> > > the params came from is set as utf-8 in the http header
> > > and> content type and firefox is believing the page is
> > > utf-8.> > It looks as though the browser isn't sending
> > > the data as UTF-8 unless> it contains text that has to
> > > be. As soon as I add a € or some other character that's
> > > utf-8 it comes through fine. Checking the params before
> > > it's decoded showed the £ as I expected to see it after
> > > if had been decoded leading me to think the form hasn't
> > > been passed as utf-8 . Any clues. anyone?
>
> > That sounds about right. Most (english) browsers default
> > to Latin-1even when they say they don't. Make sure you
> > have "enctype" set inthe opening form tag. If it still
> > doesn't work, you'll need to figureout (or as the client)
> > what the encoding is, and translate itmanipulating the
> > layers and/or encodings. But the bottom line is: if you're
> > not putting utf-8 in at some point,you won't get utf-8
> > out.
>
> For
> http://perl.wtsbroadcast.com/about/Angies_second_test_page.html
> if (in Firefox on Win32) I set
>View -> Character Encoding -> Western (Windows-1252)
> I get the £ displayed.
>
> --
> best regards,
> randy kobes
>
Just for the record it was the browser passing the form params as
Latin unless there was a character that couldn't be represented in
Latin. Then it would do as it was told and pass it as utf-8
in the end I had to use Encode::Guess to see if it was utf-8 if so
decode as that otherwise decode as iso-8859-1.
To make it a tiny bit more stable, and after a lot of trial and error
I ended up doing this.
1.Concat all the values that were passed in the form into one string.
2.Run Encode::Guess on that in order to give it enough data to have a
fair crack at it.
If $decoder is set use it to decode for values, otherwise use iso-8859-1.
Not very pretty I grant you, but the only thing that does actually
work seeing as the browser wont pass values as utf-8 all the time. Or
maybe it's the OS that's entering the text as iso-8859-1.
HTH someone someday.
Error: handles can't be shared between threads
Hi,
I am using mod_perl 2.0.0 under Windows 2000, with perl 5.8.6, Apache
2.0.54, and Apache::DBI version 0.96.
I want to create a module that uses DBI.pm for connecting to the MySQL
database, then using that module in all other modules that might need a
connection.
Here is the module I have tried:
package Site::MySQL;
use strict;
use DBI ();
sub dbh {
return DBI->connect("DBI:mysql:database=test;host=localhost", "root", undef,
{RaiseError => 0, PrintError => 1, AutoCommit => 1});
}
1;
I get the $dbh in other modules using:
my $dbh = Site::MySQL::dbh();
If I run the programs in command line, they work fine, but if I run them
using mod_perl, it gives an error in the log file:
[Thu May 19 20:36:01 2005] [error] DBD::mysql::db prepare failed: handle 2
is owned by thread 225321c not current thread 17cde94 (handles can't be
shared between threads and your driver may need a CLONE method added) at
e:/web/presa3/modules/Presa/Categories.pm line 34.\n
I have tried to use and not to use Apache::DBI but with the same results.
I don't have any idea where could be the problem. Is the module that uses
DBI bad? Isn't a good idea to create a functional module instead of an OOP
one?
Or... what can I try to make them work?
Thank you.
Teddy
Is mod_perl installed
Hey Stas, I know this has been asked a ton of time and I have read everything on the site to check if MP is installed - my problem now is I have a client who has told me over and over again that mod_perl is installed - every method documented on the site says it is not (string doesn't appear in the error log, via telnet to apache or via the lwp-request method, it also doesn't appear via httpd -l. All method above report only "Apache/2.0.46 (Red Hat) configured" The box is RH enterprise and Apache and MP2 were installed via RPM - the client called RH (to prove me wrong) and RH told him if you installed MP2 via the RH RPM then that MP2 line shouldn't appear anyplace... I find that really hard to believe BEFORE I wasn't able find anything documented about it.. Is that true? So I guess my question is, can it be said with 100% certainty that the "mod_perl 1.99" should show up in the error log (or those other documented methods) if its installed and configured properly? Is there any other ways to prove its installed or not installed? Thanks -Chris
Re: Apache2::Cookie - can't find cookie_clas.al
Andrew Wyllie <[EMAIL PROTECTED]> writes:
> my $jar = Apache2::Cookie::Jar->new( $r, VALUE_CLASS =>
> "Alta::Cookies::Cookie" );
Oops, looks like I b0rked that API in 2.05. Here's the preferred
aproach now:
my $req = APR::Request::Apache2->handle($r);
my $jar = $req->jar;
$jar->cookie_class("Alta::Cookies::Cookie");
# use $jar as if it were $jar->cookies from 2.04-dev.
> I have tried looking through the tests for libapreq, but I could not
> find a reference to Apache2::Cookie::Jar.
That package should've died anyways, since we killed off the
apreq_jar_t struct in 2.05-dev. In any case, IMO you're
better off learning the APR::Request APIs as they are
emerging now. The core is here:
# like Apache2::Request->new
my $req = APR::Request::Apache2->handle($r, ...);
my $args = $req->args; # the args table
my $body = $req->body; # the body table
my $param = $req->param; # the param (body + args) table
my $upload = $req->upload; # upload table requires APR::Request::Param
# each of the tables above are read-only (fast!) tiehash refs,
# and the values are simple scalars. But you can upgrade them
# to full params by changing the param_class, ie:
$body->param_class("APR::Request::Param");
# that way you can call methods on each value, $v->is_tainted($on_off),
# $v->charset($number), etc. Also, by turning off the is_tainted flag,
# that also means you are trusting apreq with the charset
# interpretation. That means you can do a single taint-checking
# sweep across the params in some early section of your code, and have
# later calls to $req->param("foo") marked with its proper utf8 flags.
--
Joe Schaefer
[mp2] Problem with custom config in Location
1. Problem Description:
A custom apache config directive defined in a together with
a PerlResponseHandler makes the request handling crash.
httpd.conf contains:
PerlLoadModule Xi::TestConf
XiTest test
SetHandler modperl
PerlResponseHandler Xi::Test
TestConf.pm:
package Xi::TestConf;
use Apache2::Module ();
my @directives = ( { name => 'XiTest' } );
Apache2::Module::add(__PACKAGE__, [EMAIL PROTECTED]);
sub XiTest {
my($self, $parms, $arg) = @_;
$self->{XiTest} = $arg;
}
1;
Test.pm:
package Xi::Test;
use Apache2::Const -compile => qw/OK/;
sub handler {
my $r = shift;
$r->print("Hello");
return OK;
}
1;
Result:
---
% telnet localhost 8000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test/foo HTTP/1.0
Connection closed by foreign host.
Thanks in advance for any feedback about this.
2. Used Components and their Configuration:
*** mod_perl version 1.999023
*** using
/opt/xi3/lib/perl5/site_perl/5.8.6/i686-linux-thread-multi/Apache2/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB => aprext
MP_AP_PREFIX => /opt/xi3
MP_COMPAT_1X => 0
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
*** The httpd binary was not found
*** (apr|apu)-config linking info
-L/opt/xi3/lib -laprutil-0 -lgdbm -ldb -lexpat
-L/opt/xi3/lib -lapr-0 -lrt -lm -lcrypt -lnsl -lpthread -ldl
*** /opt/xi3/bin/perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=linux, osvers=2.6.11.8, archname=i686-linux-thread-multi
uname='linux acer 2.6.11.8 #1 sat apr 30 19:16:00 cest 2005 i686 unknown
unknown gnulinux '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.3.4', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.4.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/opt/xi3/lib/perl5/5.8.6/i686-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at May 1 2005 21:29:27
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/opt/xi3/lib/perl5/5.8.6/i686-linux-thread-multi
/opt/xi3/lib/perl5/5.8.6
/opt/xi3/lib/perl5/site_perl/5.8.6/i686-linux-thread-multi
/opt/xi3/lib/perl5/site_perl/5.8.6
/opt/xi3/lib/perl5/site_perl
.
*** Packages of interest status:
Apache2 : -
Apache2::Request: -
CGI : 3.05
LWP : -
mod_perl: -
mod_perl2 : 1.999023
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by /opt/xi3/bin/mp2bug on Thu May 19 18:53:06 2005
GMT.
setting REMOTE_USER with Apache::AuthCookie for use on a 2nd server through mod_rewrite
Hi, I need to place an application which requires REMOTE_USER to be set in an external non mod_perl enabled Apache reverse proxy that is called by an internal mod_perl enabled Apache through mod_rewrite. The idea is that a directory in the internal, mod_perl enabled server would have the following config: .. #Set $r->connection->user (REMOTE_USER) PerlFixupHandler Authcookie::Based->recognize_user RewriteEngine on RewriteRule ^/appname http:external.web.server/appname [P] to cause the external app to recognize the user when it executes. Is this possible? Rafael Caceres
RE: Is mod_perl installed
Title: Re: Is mod_perl installed Hey Jay, Yes, all that is true.. the perl.conf is pulled into the httpd.conf and the first line is loading the mod_perl.so and the file does exist in the modules directory.. So by that your saying that mp2 is OK even though it doesn't appear any of those methods to check if its installed or not? I wouldn't think the existence of the conf and so file would be enough to say everything was correct. Thanks -Chris From: Jay Scherrer [mailto:[EMAIL PROTECTED]Sent: Thu 5/19/2005 5:17 PMTo: cfaust-dougotCc: mod_perlSubject: Re: Is mod_perl installed Cfaust,What does your httpd.conf file say after the modules listing?If it says something like:##load configfiles from the config directory "/etc/httpd.conf.d"#Include conf.d/*.conf#Then check there for your: perl.conf file.Within the perl.conf file you will find:LoadModule perl_module modules/mod_perl.soThen look for the perl_module in /etc/httpd/modules.This is standard placement for Redhat Linux RPMs.I have found that I can edit this perl.conf to customize my modPerl anddirectories and script aliasesOn Thu, 2005-05-19 at 14:49 -0400, cfaust-dougot wrote:> Hey Stas,> > I know this has been asked a ton of time and I have read everything on> the site to check if MP is installed - my problem now is I have a> client who has told me over and over again that mod_perl is installed> - every method documented on the site says it is not (string doesn't> appear in the error log, via telnet to apache or via the lwp-request> method, it also doesn't appear via httpd -l.> All method above report only "Apache/2.0.46 (Red Hat) configured"> > The box is RH enterprise and Apache and MP2 were installed via RPM -> the client called RH (to prove me wrong) and RH told him if you> installed MP2 via the RH RPM then that MP2 line shouldn't appear> anyplace...> > I find that really hard to believe BEFORE I wasn't able find anything> documented about it.. Is that true?> > So I guess my question is, can it be said with 100% certainty that the> "mod_perl 1.99" should show up in the error log (or those other> documented methods) if its installed and configured properly?> > Is there any other ways to prove its installed or not installed?> > Thanks> -Chris
Re: Baffling unicode wierdness
Just for the record it was the browser passing the form params as Latin unless there was a character that couldn't be represented in Latin. Then it would do as it was told and pass it as utf-8 Can you show either the actual webpage with the form or a simplified test case of it? Because I'm still pretty sure browsers don't do that if the page is correct. Certainly not Firefox, which I also use and which behaves just fine in my own UTF-8 applications, even if I only submit ASCII and umlauts that could be represented in Latin1, but no characters > 256. BTW, you can check what exactly Firefox submits by using the very useful LiveHTTPHeaders extension from http://livehttpheaders.mozdev.org. And/or you could check browsers against one of my UTF-8-capable applications at http://www.mwforum.org.
Re: [mp2] Problem with custom config in Location
Herve Guillemet wrote: 1. Problem Description: A custom apache config directive defined in a together with a PerlResponseHandler makes the request handling crash. Herve, have you considered to check the error_log before reporting a problem? Your code is improperly written and the error_log should have told you that. In the future please check that file first. Thank you. Please find an attached tarball with a testing setup that works. tar -xzvf bug-reporting-skeleton-mp2.tar.gz cd bug-reporting-skeleton-mp2 perl Makefile.PL make test ... /home/stas/httpd/prefork/bin/httpd -d /tmp/bug-reporting-skeleton-mp2/t -f /tmp/bug-reporting-skeleton-mp2/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.0.55-dev (prefork MPM) waiting 60 seconds for server to start: ok (waited 1 secs) server lapin.stason.org:8529 started t/bugok All tests successful. Files=1, Tests=1, 1 wallclock secs ( 0.87 cusr + 0.07 csys = 0.94 CPU) server lapin.stason.org:8529 shutdown -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Error: handles can't be shared between threads
On Thursday 19 May 2005 1:47 pm, Octavian Rasnita wrote: > [Thu May 19 20:36:01 2005] [error] DBD::mysql::db prepare failed: handle 2 > is owned by thread 225321c not current thread 17cde94 (handles can't be > shared between threads and your driver may need a CLONE method added) at > e:/web/presa3/modules/Presa/Categories.pm line 34.\n Are you opening database handles during server startup, in a startup.pl or a BEGIN block inside a module called from startup.pl? - Perrin
Re: [mp2] Problem with custom config in Location
forgot the attachment. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com bug-reporting-skeleton-mp2.tar.gz Description: GNU Zip compressed data
Re: Is mod_perl installed
cfaust-dougot wrote: Hey Jay, Yes, all that is true.. the perl.conf is pulled into the httpd.conf and the first line is loading the mod_perl.so and the file does exist in the modules directory.. So by that your saying that mp2 is OK even though it doesn't appear any of those methods to check if its installed or not? I wouldn't think the existence of the conf and so file would be enough to say everything was correct. If it quacks like a duck. if it walks like a duck. it must be a duck. If you don't see that mod_perl is running, that means that it doesn't. It might be installed, but if it's not enabled then it's not running. The easy way to check whether the .conf file is actually loaded is to add some garbage in it. if it's loaded httpd will fail to start. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Is mod_perl installed
Title: Re: Is mod_perl installed Thanks Stas, as always - you da man!!! -Chris From: Stas Bekman [mailto:[EMAIL PROTECTED]Sent: Thu 5/19/2005 7:18 PMTo: cfaust-dougotCc: [EMAIL PROTECTED]; mod_perlSubject: Re: Is mod_perl installed cfaust-dougot wrote:> Hey Jay,> > Yes, all that is true.. the perl.conf is pulled into the httpd.conf and> the first line is loading the mod_perl.so and the file does exist in the> modules directory..>> So by that your saying that mp2 is OK even though it doesn't appear any> of those methods to check if its installed or not? I wouldn't think the> existence of the conf and so file would be enough to say everything was> correct.If it quacks like a duck. if it walks like a duck. it must be a duck.If you don't see that mod_perl is running, that means that it doesn't.It might be installed, but if it's not enabled then it's not running.The easy way to check whether the .conf file is actually loaded is to addsome garbage in it. if it's loaded httpd will fail to start.--__Stas Bekman JAm_pH --> Just Another mod_perl Hackerhttp://stason.org/ mod_perl Guide ---> http://perl.apache.orgmailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.comhttp://modperlbook.org http://apache.org http://ticketmaster.com
Re: Error: handles can't be shared between threads
From: "Perrin Harkins" <[EMAIL PROTECTED]>
> On Thursday 19 May 2005 1:47 pm, Octavian Rasnita wrote:
> > [Thu May 19 20:36:01 2005] [error] DBD::mysql::db prepare failed: handle
2
> > is owned by thread 225321c not current thread 17cde94 (handles can't be
> > shared between threads and your driver may need a CLONE method added) at
> > e:/web/presa3/modules/Presa/Categories.pm line 34.\n
>
> Are you opening database handles during server startup, in a startup.pl or
a
> BEGIN block inside a module called from startup.pl?
>
> - Perrin
I have put the following lines in a startup.pl file which is included for
all virtualhosts (but I have a single virtual host):
use Apache::DBI ();
Apache::DBI->connect_on_init('DBI:mysql:database=test', 'root', undef,
{PrintError => 1, RaiseError => 0, AutoCommit => 1});
Then I have called the modules that use DBI in a second "preload.pl" program
which is included just in my virtual host, using:
use Site::Module1 ();
use Site::Module2 ();
...
I have noticed that if I comment out the lines from the second file, the
site works fine, but I am not sure if I won't have problems after a certain
time.
It seems that I am not allowed to launch the modules at server startup.
Thanks.
Teddy
Re: Is mod_perl installed
On Thursday 19 May 2005 2:49 pm, cfaust-dougot wrote: > The box is RH enterprise and Apache and MP2 were installed via RPM Well, you know that's going to be a problem, right? That RPM is ancient and that version of mod_perl is no longer supported. > So I guess my question is, can it be said with 100% certainty that the > "mod_perl 1.99" should show up in the error log (or those other > documented methods) if its installed and configured properly? It's always possible to change things in the source, but it seems very unlikely they would have done this for the error log message. More likely it is installed but not configured to actually be loaded when the server starts up. - Perrin
Re: Error: handles can't be shared between threads
On Fri, 2005-05-20 at 04:32 +0300, Octavian Rasnita wrote:
> I have put the following lines in a startup.pl file which is included for
> all virtualhosts (but I have a single virtual host):
>
> use Apache::DBI ();
> Apache::DBI->connect_on_init('DBI:mysql:database=test', 'root', undef,
> {PrintError => 1, RaiseError => 0, AutoCommit => 1});
>
> Then I have called the modules that use DBI in a second "preload.pl" program
> which is included just in my virtual host, using:
>
> use Site::Module1 ();
> use Site::Module2 ();
What's going on in there? Are you using Class::DBI, by any chance?
> I have noticed that if I comment out the lines from the second file, the
> site works fine, but I am not sure if I won't have problems after a certain
> time.
> It seems that I am not allowed to launch the modules at server startup.
It just means that those modules open database handles when you load
them and cache those handles in globals or closures. That will always
cause problems. You need to make them postpone opening the handles, or
stop keeping cached copies of the handles.
- Perrin
One day in #perl...
... offer bounties "i will code one task of your choice for as many hours as you code on a task of my choice" voila, no money involved and still a hook But I don't need these idea implemented If I did, I'd do them myself yeah. * CPAN upload: mod_perl-2.0.0 by GOZER whoah whoa! * Alias changes topic to 'YAPC::EU::2005 talk proposal deadline has been extended to 22nd May (next Sunday) http://conferences.yapceurope.org/2005 | http://paste.husk.org/3264 | * CPAN upload: mod_perl-2.0.0 by GOZER' * Skud sets off some party poppers Hey cool ... On behalf of #perl, congratulations team!!! Adam K
