Re: Subroutine xxxx redefined
On Wed, 22 Aug 2001, Stas Bekman wrote:
On Mon, 20 Aug 2001, matt wrote:
which I obviously want to get rid of before going to production.
^^
Anyway why do use Apache::Reload in production?
Also you don't want to have PerlWarn On in production.
We are not in production yet.
See the guide for more info.
Yes, thank you for the guide, it has been my main reference as I've
got to learn mod_perl.
What's this Loader? Does it do some File::Find dirs traversing and
automatically loads the files it finds?
Yes, it runs through some given paths, matching files that match the
type of class that it should find in those paths. It then requires
those packages. It also generates methods via AUTOLOAD to allow
you to query what classes are available.
Thanks,
Matt
--
#!/usr/bin/perl
$A='A';while(print+($A.=(grep{($A=~/(...).{78}$/)[0]eq$_} A A A
=~m{(...)}g)?A: )=~/([ A])$/){if(!(++$l%80)){print\n;sleep 1}}
Re: Installation problem...urgent
Hi there, On Tue, 21 Aug 2001, Alvaro Toro Santivanez wrote: i need run mod_perl and apache urgent If you are new to mod_perl (and Linux?)you will probably find that it is a rather complex environment. You will need to do a great deal of learning before you can quickly and easily compile, install and configure mod_perl servers. Amongst other things it simply is not safe to put a server on the Web if you don't have a reasonable understanding of how it all hangs together. This is explained for example at the top of the httpd.conf which comes with the Apache distribution. And it is not just your own machine that you might be compromising if you allow a badly configured machine on the Internet, you may be creating a place which unsociable types can use to create a lot of nuisance to other people. So be careful. On the other hand if you are working in a controlled environment like an intranet the risks may be different. Of course we don't know what you are doing because you have not been very forthcoming with the information. It will help us to help you if you try to change that. i`m red hat 7.0 user. The compiler which comes with Red Hat 7.0 has some problems, you should perhaps upgrade it, or alternatively upgrade to Red Hat 7.1 which I think contains the fixed compiler. Have you successfully configured Apache? You should satisfy yourself that you can get Apache to serve static pages before trying to get mod_perl to work. Red Hat comes with RPMs containing Apache built ready to load mod_perl as a DSO. This means that you can compile an Apache module like mod_perl and load it into Apache without having to recompile Apache, but there are things to consider and it has its disadvantages. If I were you I'd build the whole thing (including Apache) from the beginning, compiling mod_perl into Apache statically. It's very easy. Try to get used to how things go when you do that, you will start to get the feel for the sort of messages that you will see flying past on the screen, what is normal and what is not normal. Be patient. Rome wasn't built in a day. You are using many, many man-years-worth of software when you build and use a mod_perl server and it will take some time to gain even a superficial familiarity. IMHO Red Hat makes the startup and shutdown of Apache slightly more confusing than necessary but you don't need to use the same methods. Just make sure (using 'ps') that you have no other Apaches running when you try to start one which you build yourself. 'kill -15' any other Apache parent process if you like (as long as you're sure it isn't being used by anyone else:). The parent httpd usually has the lowest PID of all of them. It's all in the Guide. You will probably need to read it several times before you can claim to be a competent mod_perl administrator. You really should take a look at the SUPPORT file which comes with the mod_perl distribution. 73, Ged.
More problems with custom config directives (LONG)
Hi there,
I'm another person in the short but persistent line of people who can't
seem to get custom configuration directives to work.
I'm working with the Eagle book on this, and I've read all the relevant
threads I can find in the list archives, but since I'm having a slightly
different problem from the one my fellow strugglers were having, the
advice given to them didn't work for me.
The symptom:
On starting httpd, I get this response:
Testing user file: NewConfigDirective argumentToDirective
I tried doing away with the PerlModule directive and using the workaround
suggested by Doug MacEachern on June 9 2000, which was to put these
statements in the conf file:
Perl
delete $INC{'/path/to/ConfigModule.pm'};
require ConfigModule;
/Perl
but when I do that, I get this:
Testing user file: delete $INC{'Apache/VI/Config.pm'}
In Makefile.PL I have:
package ConfigModule;
## ... (as directed by Eagle)
my @directives = (
{ name = 'NewConfigDirective',
errmsg = 'argument to config directive',
args_how = 'TAKE1',
req_override = 'RSRC_CONF'
}
);
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg-{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for `ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
According to the Eagle book, I should be able to get rid of the 'args_how'
line as long as I provide a prototype in the subroutine definition, but it
seems I can't.
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not registering the handler
for the new directive, which might explain why I'm getting a syntax error
in the httpd.conf file when the server starts. But what would be causing
that to happen? I'm afraid I'm not familiar enough with the MakeMaker
mechanism to figure out what's going on. Then again, I'm not sure that's
really the problem, so disregard it if you think it's a red herring.
Any advice anyone can give would be very much appreciated.
-mike
=
Details:
mod_perl version used is 1.23
perl version used is 5.005_03
apache version used is 1.3.11
$ perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.5-22, archname=i686-linux
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL'
ccflags ='-Dbool=char -DHAS_BOOL'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=true, libperl=libperl.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/perl5/lib/5.00503/i686-linux/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at Aug 22 1999 14:02:34
@INC:
/usr/perl5/lib/5.00503/i686-linux
/usr/perl5/lib/5.00503
/usr/perl5/lib/site_perl/5.005/i686-linux
/usr/perl5/lib/site_perl/5.005
.
$ /usr/sbin/httpd -V
Server version: Apache/1.3.11 (Unix)
Server built: Feb 1 2000 21:17:00
Server compiled with
-D EAPI
-D EAPI_MM
-D EAPI_MM_CORE_PATH=/var/run/httpd.mm
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D USE_FCNTL_SERIALIZED_ACCEPT
default file locations cut
$ /usr/sbin/httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_perl.c
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
RE: More problems with custom config directives (LONG)
On Wed, 22 Aug 2001, Matt Sergeant wrote:
-Original Message-
From: Michael Styer [mailto:[EMAIL PROTECTED]]
In Makefile.PL I have:
snip abbreviated makefile code listing
I'm assuming you have more than that... :-)
Yes. :)
It actually looks like this:
package ConfigModule;
use ExtUtils::MakeMaker;
use Apache::ExtUtils qw(command_table);
use Apache::src ();
my @directives = (
{ name = 'ConfigDirective',
errmsg = 'name of the handler module',
args_how = 'TAKE1',
req_override = 'RSRC_CONF'
}
);
command_table(\@directives);
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
## required makefile stuff
);
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg-{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for
`ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
That's because ConfigModule.pm isn't loaded at the time. You'd have to
require() it or use() it.
Even when the makefile is declared as 'package ConfigModule;' initally?
It seems strange that I would need to write 'package Foo; use Foo;'. Maybe
I don't understand how that works. Would I need a 'use lib ...' statment
there so Makefile.PL would know where to look for ConfigModule.pm?
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not
registering the handler for the new directive, which might explain why
I'm getting a syntax error in the httpd.conf file when the server
starts. But what would be causing that to happen? I'm afraid I'm not
familiar enough with the MakeMaker mechanism to figure out what's
going on. Then again, I'm not sure that's really the problem, so
disregard it if you think it's a red herring.
Are you getting a ConfigModule.xs file written and compiled OK?
Yeah, there don't seem to be any problems writing and compling
ConfigModule.xs. I can get through make, make test, and make install
without any problems; it's just when it comes to starting the server that
I run into the problem.
Details:
mod_perl version used is 1.23
There have been some fairly serious config directives bugs fixed since then.
I suggest an upgrade.
I'll look into it, but my sysadmins are worried that upgrading is going to
break, in strange and obscure ways, the multiple live commercial sites we
have running on our servers. Are there any resources available I might be
able to use to reassure them?
Thanks for your help.
-mike
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
Re: Embperl, modules, cleanup and the stop button
My feeling that this cleanup is infact unnecessary (all though worth having regardless), as the pipeline nature of the request (call database for *all* data required, *then* output), any database calls (and corresponding locks) will have completed before the abort (SIGPIPE) is recognised. This should go double for embperl, which executes all perl code before outputting any headers and data. The connection is only aborted, when data is send. So it's true that normaly there is no abort before the whole page has processed within Embperl., but there are other reason a page may fail. So it's a good idea to have a cleanup. In an Embperl page you can define a function called CLEANUP which will be call _always_, regardless what fails. It will be called after all content is send to the browser. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: More problems with custom config directives (LONG)
-Original Message-
From: Michael Styer [mailto:[EMAIL PROTECTED]]
Hi there,
I'm another person in the short but persistent line of people
who can't
seem to get custom configuration directives to work.
:-)
In Makefile.PL I have:
package ConfigModule;
## ... (as directed by Eagle)
my @directives = (
{ name = 'NewConfigDirective',
errmsg = 'argument to config directive',
args_how = 'TAKE1',
req_override = 'RSRC_CONF'
}
);
I'm assuming you have more than that... :-)
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg-{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for
`ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
That's because ConfigModule.pm isn't loaded at the time. You'd have to
require() it or use() it.
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not
registering the handler
for the new directive, which might explain why I'm getting a
syntax error
in the httpd.conf file when the server starts. But what would
be causing
that to happen? I'm afraid I'm not familiar enough with the MakeMaker
mechanism to figure out what's going on. Then again, I'm not
sure that's
really the problem, so disregard it if you think it's a red herring.
Are you getting a ConfigModule.xs file written and compiled OK?
Details:
mod_perl version used is 1.23
There have been some fairly serious config directives bugs fixed since then.
I suggest an upgrade.
Matt.
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
RE: More problems with custom config directives (LONG)
-Original Message- From: Michael Styer [mailto:[EMAIL PROTECTED]] That's because ConfigModule.pm isn't loaded at the time. You'd have to require() it or use() it. Even when the makefile is declared as 'package ConfigModule;' initally? It seems strange that I would need to write 'package Foo; use Foo;'. Maybe I don't understand how that works. Would I need a 'use lib ...' statment there so Makefile.PL would know where to look for ConfigModule.pm? Nah, you can do require(ConfigModule.pm) and it'll work. Are you getting a ConfigModule.xs file written and compiled OK? Yeah, there don't seem to be any problems writing and compling ConfigModule.xs. I can get through make, make test, and make install without any problems; it's just when it comes to starting the server that I run into the problem. OK, can you describe the problem a little more clearly? The Testing user file bit doesn't seem to come from anywhere - any ideas where it's coming from??? Details: mod_perl version used is 1.23 There have been some fairly serious config directives bugs fixed since then. I suggest an upgrade. I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: More problems with custom config directives (LONG)
I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. The (possibly a slightly obvious point) way I'd recommend dealing with this is to test everything on your development machine(s), make sure it all works, and the upgrade hasn't broken anything, and then upgrade the live systems, with plans to revert if it all goes wrong, and so on - the same way you'd make any other serious upgrade to an important live system. If you don't have systems you can test everything out on, you have a serious problem and should probably deal with this first. Michael http://www.iii.co.uk Interactive Investor International is a leading UK Internet personal finance service that provides individuals with the capability to identify, compare, monitor and buy online a number of financial products and services. Interactive Investor Trading Limited, a subsidiary of Interactive Investor International plc, is regulated by the SFA.
RE: More problems with custom config directives (LONG)
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 22, 2001 6:41 AM To: 'Michael Styer'; Matt Sergeant Cc: [EMAIL PROTECTED] Subject: RE: More problems with custom config directives (LONG) [snip] I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. well, I think this really depends on your situation. directive handlers are not as robust as they could be, we all know that. but I've had Apache::Dispatch (which uses directive handlers) running in production since December without any issues. bottom line is (as always) never put anything into production that hasn't been sufficiently stressed in development. --Geoff
RE: More problems with custom config directives (LONG)
On Wed, 22 Aug 2001, Matt Sergeant wrote: OK, can you describe the problem a little more clearly? The Testing user file bit doesn't seem to come from anywhere - any ideas where it's coming from??? I had assumed it was coming from Apache, but your question made me suspicious. After a little digging, I discovered it's coming from a userv script that is used to restart development apache daemons so all us lowly developers don't need to have su priveleges ;). I won't bother you with the details, except to say it didn't permit adding config directives. Having fixed that, the server restarts fine, which means the new directives are getting read properly, but when I try to hit that development vhost with my browser the child segfaults. Which is where I'm stuck now. Details: mod_perl version used is 1.23 There have been some fairly serious config directives bugs fixed since then. I suggest an upgrade. I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. Don't worry, it's all happening on an isolated development server, I was just wondering whether there are any resources that indicate what things might break when upgrading from 1.23 to 1.24. But if I can't get this working soon time pressure will force me to use the functional but much less elegant PerlSetVar method, and an upgrade will be irrelevant. Any advice (from anyone) on how to fix the segfault problem would still be appreciated, though. Many thanks to all for the advice I've received already. -mike -- Michael Styer [EMAIL PROTECTED] phone: 020 7603 5723107 Shepherd's Bush Rd fax: 020 7603 2504 London W6 7LP
RE: More problems with custom config directives (LONG)
Don't worry, it's all happening on an isolated development server, I was just wondering whether there are any resources that indicate what things might break when upgrading from 1.23 to 1.24. But if I can't get this working soon time pressure will force me to use the functional but much less elegant PerlSetVar method, and an upgrade will be irrelevant. Any advice (from anyone) on how to fix the segfault problem would still be appreciated, though. you'll want to move to at least 1.25 with directive handlers (well, actually 1.24_01 IIRC) due to a major bug fix, the nature of which is escaping me this morning but can be found in the archives. --Geoff
Re: Subroutine xxxx redefined
On Wed, 22 Aug 2001, matt wrote: On Wed, 22 Aug 2001, Stas Bekman wrote: On Mon, 20 Aug 2001, matt wrote: which I obviously want to get rid of before going to production. ^^ Anyway why do use Apache::Reload in production? Also you don't want to have PerlWarn On in production. We are not in production yet. whooph :) See the guide for more info. Yes, thank you for the guide, it has been my main reference as I've got to learn mod_perl. :) What's this Loader? Does it do some File::Find dirs traversing and automatically loads the files it finds? Yes, it runs through some given paths, matching files that match the type of class that it should find in those paths. It then requires those packages. It also generates methods via AUTOLOAD to allow you to query what classes are available. The behavior you see [xxx redefined] is normal. Apache::Reload reloads files because it detects that they have changed and then you see all the reload messages. Now why your code get Apache::Reload confused and makes it believe that your modules were changed is the question. Is there a chance that you touch(1) the modules in question, which causes their timestamp to be updated, and thus be newer than the one stored in Apache::Reload's memory? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Subroutine xxxx redefined
Stas,
The behavior you see [xxx redefined] is normal. Apache::Reload
reloads files because it detects that they have changed and then you
see all the reload messages. Now why your code get Apache::Reload
confused and makes it believe that your modules were changed is
the question.
I thought this was the case, after reading some of the
archives. However in my original post:
I am using Apache::Reload and from other posts it looks like
getting redefined messages is expected behaviour. However, when
I no longer use Apache::Reload, I still get the copious logging,
which I obviously want to get rid of before going to production.
I noted that even after removing all traces of Apache::Reload, the
problem won't go away.
Is there a chance that you touch(1) the modules in question, which
causes their timestamp to be updated, and thus be newer than the
one stored in Apache::Reload's memory?
Checking with ls(1) immediately after an apache restart, I can
see that the status and timestamp is unchanged, but (as expected)
the access time is set to the current time. While I haven't checked
the Apache::Reload source, it seems pointless to update modules if
only their access times have changed.
Any other suggestions will be gratefully received!
Matt
--
#!/usr/bin/perl
$A='A';while(print+($A.=(grep{($A=~/(...).{78}$/)[0]eq$_} A A A
=~m{(...)}g)?A: )=~/([ A])$/){if(!(++$l%80)){print\n;sleep 1}}
RE: Problem with DBD::Oracle with mod_perl
On Wed, Aug 22, 2001 at 09:42:59AM -0400, Perrin Harkins wrote: Are you using Apache::DBI? Are you opening a connection in the parent process (in startup.pl or equivalent)? Yes, yes. Don't open a connection during startup. If you do, it will be shared when Apache forks, and sharing a database handle is bad for the same reasons sharig a file handle is. Open a connection in the child process instead. You can use connect_on_init() from Apache::DBI if you like. I misunderstood you. I was using connect_on_init. With or without Apache::DBI, it fails I've SEEN this. It SUCKED. Then I figured it out. And *IF* it's the same thing, then: ORACLE has to be reconfigured, to allow more connections. By default, there is a PROCESS max (200), because Oracle spawns a new process per connection. And then there is a WHOLE different operating mode, called MTS. You have to modify init.ora and activate MTS. The relevant section from MY Oracle config (8.1.5 or 8.1.6, I forget): # # This parameter turns on MTS mts_servers = 1 # min value mts_max_dispatchers = 5 # max value mts_dispatchers = (PROTOCOL=TCP)(DISPATCHERS=2) sessions = 1500 HTH L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: Oracle::DBD under mod_perl on Sun/Solaris
Hi there, On Wed, 22 Aug 2001, Alex Povolotsky wrote: DBD::Oracle::db prepare failed: ORA-03120: two-task conversion routine: [snip] DBD::Oracle::db prepare failed: ORA-03113: end-of-file on communication channel (DBD: oopen error) and EVERY connect to database fails since that. I was NOT able to reproduce this bug outside of mod_perl. Are you running out of memory? 73, Ged.
Apache::DBI
I am a bit confused! Can Apache::DBI handle db calls through proxies? -r
Re: Apache::DBI
On Wed, Aug 22, 2001 at 12:34:11PM -0700, Rasoul Hajikhani wrote: I am a bit confused! Can Apache::DBI handle db calls through proxies? -r It should be able to handle anything DBI handles. Just `use' it before `use'ing any other DBI modules and you shouldn't have to change any of your code, afaik. --jim
Re: Subroutine xxxx redefined
On Wed, 22 Aug 2001, matt wrote: Stas, The behavior you see [xxx redefined] is normal. Apache::Reload reloads files because it detects that they have changed and then you see all the reload messages. Now why your code get Apache::Reload confused and makes it believe that your modules were changed is the question. I thought this was the case, after reading some of the archives. However in my original post: I am using Apache::Reload and from other posts it looks like getting redefined messages is expected behaviour. However, when I no longer use Apache::Reload, I still get the copious logging, which I obviously want to get rid of before going to production. I noted that even after removing all traces of Apache::Reload, the problem won't go away. Oh, OK, so it has nothing to do with Apache::Reload, sorry for missing this point in your original post. Is there a chance that you touch(1) the modules in question, which causes their timestamp to be updated, and thus be newer than the one stored in Apache::Reload's memory? Checking with ls(1) immediately after an apache restart, I can see that the status and timestamp is unchanged, but (as expected) the access time is set to the current time. While I haven't checked the Apache::Reload source, it seems pointless to update modules if only their access times have changed. So it has something to do with you Loader. May be you are using do() instead of require()/use(). Or may be you mangle with %INC? Something forces the reload of your files. I'd suggest putting something like: use Carp; cluck(I was loaded); in one of the files run the server in single server mode (httpd -X) and check the trace on the second reload. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Subroutine xxxx redefined
Stas Bekman wrote: Something forces the reload of your files. I'd suggest putting something like: use Carp; cluck(I was loaded); in one of the files run the server in single server mode (httpd -X) and check the trace on the second reload. Nice idea. You might also try 'warn @INC' in one of your modules to see what the include path looks like. You might have a path appearing twice in @INC.
Re: Subroutine xxxx redefined
On Thu, 23 Aug 2001, Jeremy Howard wrote: Stas Bekman wrote: Something forces the reload of your files. I'd suggest putting something like: use Carp; cluck(I was loaded); in one of the files run the server in single server mode (httpd -X) and check the trace on the second reload. Nice idea. You might also try 'warn @INC' in one of your modules to see what the include path looks like. You might have a path appearing twice in @INC. Hmm, let's say I do have some path twice. What gives? It's %INC that matters here and not @INC. Or do you mean something else? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Problem with DBD::Oracle with mod_perl
Are you using Apache::DBI? Are you opening a connection in the parent process (in startup.pl or equivalent)? Yes, yes. Don't open a connection during startup. If you do, it will be shared when Apache forks, and sharing a database handle is bad for the same reasons sharig a file handle is. Open a connection in the child process instead. You can use connect_on_init() from Apache::DBI if you like. - Perrin
Re: Problem with DBD::Oracle with mod_perl
On Wed, Aug 22, 2001 at 09:42:59AM -0400, Perrin Harkins wrote: Are you using Apache::DBI? Are you opening a connection in the parent process (in startup.pl or equivalent)? Yes, yes. Don't open a connection during startup. If you do, it will be shared when Apache forks, and sharing a database handle is bad for the same reasons sharig a file handle is. Open a connection in the child process instead. You can use connect_on_init() from Apache::DBI if you like. I misunderstood you. I was using connect_on_init. With or without Apache::DBI, it fails Alex.
Re: Problem with DBD::Oracle with mod_perl
After some time of work (about hundred of requests), I get DBD::Oracle::db prepare failed: ORA-03113: end-of-file on communication channel (DBD: error possibly near * indicator at char 1 in '*select slogan_text from slogans') at /usr/local/www/lib/SQL.pm line 221. and all Oracle-using perl programs within Apache stops to work until I restart Apache. With two clients fetching a page both at one time, I'm 100% getting this in less than a minute. Are you using Apache::DBI? Are you opening a connection in the parent process (in startup.pl or equivalent)? - Perrin
Re: Problem with DBD::Oracle with mod_perl
On Wed, Aug 22, 2001 at 09:07:59AM -0400, Perrin Harkins wrote: (DBD: error possibly near * indicator at char 1 in '*select slogan_text from slogans') at /usr/local/www/lib/SQL.pm line 221. Are you using Apache::DBI? Are you opening a connection in the parent process (in startup.pl or equivalent)? Yes, yes. ... whithout it - runs... a little longer. Alex.
