mp guide: sections -> leaks
Hello, I've had problems with sections causing leaks with graceful restart, at least with some versions/setups of mod_perl. I thought the problem should be noted in the guide. A patch is attached for: http://perl.apache.org/docs/1.0/guide/troubleshooting.pod.orig I no longer have my test code, it was a while ago. Here's the link and mail exchange that confirmed my tests: http://aspn.activestate.com/ASPN/Mail/Message/modperl/304620 > >> > I have a static Solaris compilation, and have the same problems > >> > where the parent seems to grow by 1M each HUP. > >> > >> that's strange, do you have PerlFreshRestart On or some sections? > >> otherwise, kill -HUP with a static modperl is a noop. > > > >You got me! I have sections ... but I didn't know > >it was such a crime. Pretty bizarre behavior if you ask me. > > it's not a crime, but if you're running Perl code during restart there's a > strong chance you'll be growing the server size. i agree 1M is bizarre > though. Brad -- ... There is dignity in paucity of words. ... -- Hagakure --- troubleshooting.pod.orig 2004-05-04 16:57:24.0 +1000 +++ troubleshooting.pod.new 2004-05-04 17:03:48.0 +1000 @@ -767,6 +767,10 @@ See the I explanation at the section: L +Also, be aware that sections can also cause leaks during +graceful restarts. See the (sub)thread: +http://aspn.activestate.com/ASPN/Mail/Message/modperl/304620 + =head1 OS Specific Notes =head2 RedHat Linux -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $r->auth_name
Fred Moyer wrote: >>> >>> Is there an mp2 implementation of $r->auth_name? I'm working with >>> Apache::AuthCookie in a native mp2 environment and am getting an error >>> message of: >> >> >> I believe this module has been ported to mp2 already. you might want to >> check the archives so you don't end up doing more work than you need. > > I followed the threads to > http://marc.theaimsgroup.com/?l=apache-modperl&m=105264164428847&w=2 > > Most of this I got working. try http://marc.theaimsgroup.com/?l=apache-modperl&m=105978462618590&w=2 which notes that a pre-release of 3.05 supports mp2 and is available from here: https://sourceforge.net/project/showfiles.php?group_id=12701 > >>> >>> Can't locate class method 'Apache::RequestRec::auth_name' via package >>> 'Apache::ReqestRec' at Apache/AuthCookie.pm line 18 >>> >>> I've found references to $r->auth_name and ap_auth_name in the source >>> but have not come across it in the api docs. >> >> >> you need to >> >> use Apache::Access (); >> >> first. > > > Aha, the missing piece. Thanks! sure :) --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mason/mod_perl debugging help needed
Hi Andrew, > can reproduce the problem easily, and upon closer inspection with > strace and gdb I can tell that Apache is hanging in the same place Well, where is it? Also, what versions of various things are you running? And when you say "hang indefinitely"... what do you mean? Aaron -- Aaron Ross <[EMAIL PROTECTED]> Plus Three -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1] subprocess_env and non-mod_perl handlers
Geoffrey Young wrote on 5/3/04, 8:02 PM: > > If I do the void subprocess_env trick: > > > > $r->subprocess() > > > > before retrieving $something, then it's populated along with the > rest of > > the environment. > > that only affects %ENV, not the ability of $r->subprocess_env to grab > something from the subprocess_env table. %ENV is not automatically > populated with the contents of subprocess_env, so if you're really > talking > about %ENV then your Example 2 + subprocess_env() trick sounds right. Nope, I'm talking about the table itself (via subprocess_env), which is why I am confused. > > > > > However, as mentioned in many of the docs/books, this is expensive > and I > > really only need the one variable. > > > > I've also tried walking the subprocess_env table in the perl handler, > > but the value set in the C handler is not there. > > that's really strange. are you sure that you are not removing it in your > application someplace? try tweaking the test tarball I mentioned bit > by bit > until it has the relevant logic from your code in it. I can't tell > you the > number of bugs I've "fixed" by trying to reproduce the bug, only to > find I > was the bug :) Understood. :-) Thanks for the code, I'll keep working on it trying to narrow down the problem. At least I know that the behavior I'm seeing is definitely wrong and it should work without the void subprocess_env call. > > > > > Are the C API subprocess_env table and the mod_perl API subprocess_env > > table distict until something (like the void call) merges the > tables? Is > > this some sort of scoping issue between C and Perl? > > it shouldn't be, so long as you're hitting the tables directly with > $r->subprocess_env. %ENV is another matter entirely. Thanks, --John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ANNOUNCE: Bricolage 1.8.0 Arrives!
It is with great pleasure that the Bricolage development team announces the release of Bricolage 1.8.0. The culmination of over 15 months in development, with contributions from over 20 independent developers, and new features sponsored by numerous organizations world-wide, version 1.8.0 represents a significant new pinnacle for the much-lauded open-source content management and publishing system. This release offers more new features, improvements, and performance gains than any previous release. There are so many, in fact (over 120), that they can't effectively be included in this email. Here are some of the highlights: * Support for managing multiple sites from a single Bricolage installation. Each site has its own categories, templates, document types, and workflows, and collaboration across sites is supported by document aliasing and shared workflow desks. * Significant performance boosts to search queries and URI uniqueness validation. * Email document distribution, which can be used to email the files generated by an output channel to one or more email addresses. * A greatly simplified and flexible templating and element API. * Template sandboxes to enable template development without interfering with production templates. * Support for Template Toolkit templates (http://www.template-toolkit.org). * New "Publish" and "Recall" permissions, for improved workflow management. * Per-user preferences. * Document formatting at publish time, rather than publish scheduling time. * New German and Mandarin localizations. * Image thumbnails and icons for all media documents. * Support for HTMLArea WYSIWYG editing with HTMLArea. See http://www.interactivetools.com/products/htmlarea/. For a complete list of the changes, see the release notes and changes list at http://sourceforge.net/project/shownotes.php?release_id=235793. For the complete history of ongoing changes in Bricolage, see Bric::Changes at http://www.bricolage.cc/docs/Bric/Changes.html. Download Bricolage 1.8.0 now from the SourceForge download page at http://sourceforge.net/project/showfiles.php?group_id=34789, and from the Kineticode download page at http://www.kineticode.com/bricolage/index2.html. ABOUT BRICOLAGE Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason, HTML::Template, and Template Toolkit support for flexibility, and many other features. It operates in an Apache/mod_perl environment and uses the PostgreSQL RDBMS for its repository. A comprehensive, actively-developed open source CMS, Bricolage was hailed as "Most Impressive" in 2002 by eWeek. Enjoy! --The Bricolage Team -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl File Extension Configuration instead of a Path Configuration
DJ wrote: I dont know if this has been answered, since i deleted my email but the answer is: SetHandler perl-script PerlHandler Your::Module Thanks DJ! I did get this earlier: PerlModule Apache::Registry AddHandler perl-script .mpl PerlHandler Apache::Registry so incorporating the 2 it would be: SetHandler perl-script PerlHandler Apache::Registry After mod_perl is built as a DSO in Apache? Is either method more preferable? I'd do either in the main config section or in an section? TIA -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp guide: sections -> leaks
Brad Bowman wrote: Hello, I've had problems with sections causing leaks with graceful restart, at least with some versions/setups of mod_perl. I thought the problem should be noted in the guide. A patch is attached for: http://perl.apache.org/docs/1.0/guide/troubleshooting.pod.orig I no longer have my test code, it was a while ago. Here's the link and mail exchange that confirmed my tests: http://aspn.activestate.com/ASPN/Mail/Message/modperl/304620 Thanks for the patch, Brad. But are you sure this is still the case with the latest mp1? This thread that you've quoted is 4 years old. And it doesn't show any code that may cause such a leak. Or do you refer to this note: it's not a crime, but if you're running Perl code during restart there's a strong chance you'll be growing the server size. i agree 1M is bizarre though. In which case this should probably mention: +Also, be aware that sections can also cause leaks during +graceful restarts. See the (sub)thread: +http://aspn.activestate.com/ASPN/Mail/Message/modperl/304620 "when running some perl code"? as in 'besides using sections to do dynamic configuration'? __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
make test hangs
Hi, I'm trying to get mod_perl-1.99_13 to compile with apache 2.0.49 and perl 5.6.2 -bash-2.05b# /usr/opt/perl-5.6.2/bin/perl -VSummary of my perl5 (revision 5.0 version 6 subversion 2) configuration: Platform: osname=hpux, osvers=11.00, archname=PA-RISC2.0 uname='hp-ux cars-l b.11.00 u 9000800 134921527 unlimited-user license ' config_args='-Accflags=+Z -Accflags=-DPERL_POLLUTE -Dprefix=/usr/opt/perl-5.6.2 -Doptimize=-g -Dloclibpth=/usr/opt/perl-5.6.2/lib /lib /usr/lib /usr/ccs/lib /usr/opt/libiconv-1.9.1/lib /usr/opt/readline-4.3/lib /usr/opt/openssl-0.9.7d/lib /usr/opt/ncurses-5.3/lib /usr/opt/gettext-0.12.1/lib /usr/opt/jpeg.v6b/lib /opt/informix/lib /usr/opt/zlib-1.1.4/lib /usr/opt/db-4.1.25/lib /usr/opt/expat-1.95.6/lib /usr/opt/gzip-1.2.4/lib /usr/opt/freetds-0.61/lib /usr/opt/libpng-1.2.5/lib /usr/opt/bzip2-1.0.2/lib /usr/opt/gdbm-1.8.3/lib /usr/opt/freetype-2.1.5/lib /usr/opt/gd-2.0.15/lib /usr/opt/tiff-v3.5.7/lib /opt/default/lib -Dlocincpth=/usr/opt/perl-5.6.2/include /include /usr/include /usr/ccs/include /usr/opt/libiconv-1.9.1/include /usr/opt/readline-4.3/include /usr/opt/openssl-0.9.7d/include /usr/opt/ncurses-5.3/include /usr/opt/gettext-0.12.1/include /usr/opt/jpeg.v6b/include /opt/informix/incl /usr/opt/zlib-1.1.4/include /usr/opt/db-4.1.25/include /usr/opt/expat-1.95.6/include /usr/opt/gzip-1.2.4/include /usr/opt/freetds-0.61/include /usr/opt/libpng-1.2.5/include /usr/opt/bzip2-1.0.2/include /usr/opt/gdbm-1.8.3/include /usr/opt/freetype-2.1.5/include /usr/opt/gd-2.0.15/include /usr/opt/tiff-v3.5.7/include /opt/default/include -Dcc=/opt/ansic/bin/cc -Dlibs=-lnsl -lnm -lndbm -lgdbm -ldb -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lcl -Ubincompat5005 -d -e' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='/opt/ansic/bin/cc', ccflags =' -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +Z -DPERL_POLLUTE -DDEBUGGING -I/usr/opt/perl-5.6.2/include -I/usr/opt/libiconv-1.9.1/include -I/usr/opt/readline-4.3/include -I/usr/opt/openssl-0.9.7d/include -I/usr/opt/ncurses-5.3/include -I/usr/opt/gettext-0.12.1/include -I/usr/opt/jpeg.v6b/include -I/opt/informix/incl -I/usr/opt/zlib-1.1.4/include -I/usr/opt/db-4.1.25/include -I/usr/opt/expat-1.95.6/include -I/usr/opt/freetds-0.61/include -I/usr/opt/libpng-1.2.5/include -I/usr/opt/bzip2-1.0.2/include -I/usr/opt/gdbm-1.8.3/include -I/usr/opt/freetype-2.1.5/include -I/usr/opt/gd-2.0.15/include -I/usr/opt/tiff-v3.5.7/include -I/opt/default/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ', optimize='-g', cppflags='-Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +Z -DPERL_POLLUTE -DDEBUGGING -I/usr/opt/perl-5.6.2/include -I/usr/opt/libiconv-1.9.1/include -I/usr/opt/readline-4.3/include -I/usr/opt/openssl-0.9.7d/include -I/usr/opt/ncurses-5.3/include -I/usr/opt/gettext-0.12.1/include -I/usr/opt/jpeg.v6b/include -I/opt/informix/incl -I/usr/opt/zlib-1.1.4/include -I/usr/opt/db-4.1.25/include -I/usr/opt/expat-1.95.6/include -I/usr/opt/freetds-0.61/include -I/usr/opt/libpng-1.2.5/include -I/usr/opt/bzip2-1.0.2/include -I/usr/opt/gdbm-1.8.3/include -I/usr/opt/freetype-2.1.5/include -I/usr/opt/gd-2.0.15/include -I/usr/opt/tiff-v3.5.7/include -I/opt/default/include' ccversion='A.11.01.25171.GP', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='/usr/bin/ld', ldflags =' -L/usr/opt/perl-5.6.2/lib -L/lib -L/usr/lib -L/usr/ccs/lib -L/usr/opt/libiconv-1.9.1/lib -L/usr/opt/readline-4.3/lib -L/usr/opt/openssl-0.9.7d/lib -L/usr/opt/ncurses-5.3/lib -L/usr/opt/gettext-0.12.1/lib -L/usr/opt/jpeg.v6b/lib -L/opt/informix/lib -L/usr/opt/zlib-1.1.4/lib -L/usr/opt/db-4.1.25/lib -L/usr/opt/expat-1.95.6/lib -L/usr/opt/gzip-1.2.4/lib -L/usr/opt/freetds-0.61/lib -L/usr/opt/libpng-1.2.5/lib -L/usr/opt/bzip2-1.0.2/lib -L/usr/opt/gdbm-1.8.3/lib -L/usr/opt/freetype-2.1.5/lib -L/usr/opt/gd-2.0.15/lib -L/usr/opt/tiff-v3.5.7/lib -L/opt/default/lib' libpth=/usr/opt/perl-5.6.2/lib /lib /usr/lib /usr/ccs/lib /usr/opt/libiconv-1.9.1/lib /usr/opt/readline-4.3/lib /usr/opt/openssl-0.9.7d/lib /usr/opt/ncurses-5.3/lib /usr/opt/gettext-0.12.1/lib /usr/opt/jpeg.v6b/lib /opt/informix/lib /usr/opt/zlib-1.1.4/lib /usr/opt/db-4.1.25/lib /usr/opt/expat-1.95.6/lib /usr/opt/gzip-1.2.4/lib /usr/opt/freetds-0.61/lib /usr/opt/libpng-1.2.5/lib /usr/opt/bzip2-1.0.2/lib /usr/opt/gdbm-1.8.3/lib /usr/opt/freetype-2.1.5/lib /usr/opt/gd-2.0.15/lib /usr/opt/tiff-v3.5.7/lib /opt/default/lib libs=-lnsl -lnm -lndbm -lgdbm -ldb -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lcl perllibs=-lnsl -l
Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache
[Olivier, please keep things on the list. Thanks] So you have a bunch of these errors: /usr/lib/pa20_64/dld.sl: Unsatisfied code symbol 'modperl_bucket_sv_create' in Is nm(1) working on your platform? If so, please try: nm /path/to/your/httpd | grep modperl_bucket_sv_create It does not find modperl_bucket_sv_create in httpd file. Show us the linking output when it creates mod_perl.a. After the build is complete on my machine I'd do: % rm src/modules/perl/mod_perl.a % make cd "src/modules/perl" && make -f Makefile.modperl make[1]: Entering directory `/home/stas/apache.org/mp2-xcpt/src/modules/perl' rm -f mod_perl.a ar crv mod_perl.a mod_perl.o modperl_interp.o modperl_tipool.o modperl_log.o modperl_config.o modperl_cmd.o modperl_options.o modperl_callback.o modperl_handler.o modperl_gtop.o modperl_util.o modperl_io.o modperl_io_apache.o modperl_filter.o modperl_bucket.o modperl_mgv.o modperl_pcw.o modperl_global.o modperl_env.o modperl_cgi.o modperl_perl.o modperl_perl_global.o modperl_perl_pp.o modperl_sys.o modperl_module.o modperl_svptr_table.o modperl_const.o modperl_constants.o modperl_apache_compat.o modperl_error.o modperl_hooks.o modperl_directives.o modperl_flags.o modperl_xsinit.o a - mod_perl.o a - modperl_interp.o a - modperl_tipool.o a - modperl_log.o a - modperl_config.o a - modperl_cmd.o a - modperl_options.o a - modperl_callback.o a - modperl_handler.o a - modperl_gtop.o a - modperl_util.o a - modperl_io.o a - modperl_io_apache.o a - modperl_filter.o a - modperl_bucket.o a - modperl_mgv.o a - modperl_pcw.o a - modperl_global.o a - modperl_env.o a - modperl_cgi.o a - modperl_perl.o a - modperl_perl_global.o a - modperl_perl_pp.o a - modperl_sys.o a - modperl_module.o a - modperl_svptr_table.o a - modperl_const.o a - modperl_constants.o a - modperl_apache_compat.o a - modperl_error.o a - modperl_hooks.o a - modperl_directives.o a - modperl_flags.o a - modperl_xsinit.o : mod_perl.a So you are after this line: a - modperl_bucket.o Checking: % nm mod_perl.a | grep modperl_bucket_sv_create 01e2 T modperl_bucket_sv_create So as you can see it has this symbol. You can check the original file as well: % nm modperl_bucket.o | grep modperl_bucket_sv_create 01e2 T modperl_bucket_sv_create Can you please run those commands for us? [the rest in another email, to keep issues separate] -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2 static build on HPUX11i: tests
Here are the results you asked for :
t/TEST -clean
t/TEST -v t/api/module.t t/apr/netlib.t t/compat/conn_rec.t
t/modperl/setupenv.t t/preconnection/note.t
Thanks. So it all comes down to two issues.
1) Apache::Module::loaded('mod_perl.so')
t/api/module1..11
# testing : Apache::Module::loaded('mod_perl.so')
# expected: 1
# received: 0
not ok 6
It makes sense that mod_perl.so is not loaded, since it doesn't exist.
Philippe, I wonder how this test has passed for you.
2) the rest of the tests fail on $ENV{REMOTE_ADDR} and $r->remote_address
returning 0.0.0.0 instead of 127.0.0.1. Sounds like an ipv6 issue to me. but
since all those running ipv6 didn't report that problem that sounds as either
a bug in Apache on HPUX11i or some OS issues. Olivier, could you try a mod_cgi
script that prints out $ENV{REMOTE_ADDR}, when your client is running on the
same machine and when it's running from another machine? Thanks.
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: make test hangs
William Fulmer wrote: Hi, I'm trying to get mod_perl-1.99_13 to compile with apache 2.0.49 and perl 5.6.2 That's insufficient, William. Please see: http://perl.apache.org/bugs/ [...] It hangs on api/request_rec. Try to figure out which sub-test is it hanging on. Try this trick: http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace tusc of the httpd process gives the folloing over and over again: select(0, NULL, NULL, NULL, 0x7f7f0b10) . [entry] select(0, NULL, NULL, NULL, 0x7f7f0b10) . = 0 waitpid(4294967295, WIFEXITED(0), WNOHANG|WUNTRACED) [entry] waitpid(-1, WIFEXITED(0), WNOHANG|WUNTRACED) = 0 which httpd process are you tracing? There is more than one. Looks like you are tracing the parent process. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2 static build on HPUX11i: invalid ldflags
[EMAIL PROTECTED] wrote: BTW, I had to modify a bit the "config_vars.mk" file from Apache. You didn't mention what did you have to modify there. Sorry, I didn't make myself clear : Apache and Perl are compiled with the same compiler and the same options. The only problem that I found is for the "ldflads". The way Perl is linking is by calling the "cc" command. The way modperl is linking is by calling "/bin/ld". The first command is accepting the +DD64 (and needs this flag to compile in 64 bits), but the second command doesn't know this option (and does not need it to link in 64 bits). So I had to remove this in the ldflags from the config. modperl does so, because Perl told it to do so. Your perl -V has: ld='/usr/bin/ld', ldflags =' +DD64 -L/usr/local/lib -L/lib/pa20_64' If that's not correct (which appears to be the case), you must report this problem to the perl5-porters list via perlbug(1). Once you did so, please report back the outcome of this bug report. But we certainly add any necessary workarounds so you won't have to fix that manually. But first I want to hear what p5p has to say about this. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1] subprocess_env and non-mod_perl handlers
Geoffrey Young wrote on 5/3/04, 8:02 PM:
> > Example 2:
> >
> > Basically the same except I have a C handler defined for TypeHandler
> and
> > a mod_perl handler defined for FixupHandler. When the C code does:
> >
> > ap_table_set(r->subprocess_env, "TEST", "value");
> >
> > The mod_perl handler for FixupHandler doesn't see it using:
> >
> > $something = $r->subprocess_env("TEST");
> > However, as mentioned in many of the docs/books, this is expensive
> and I
> > really only need the one variable.
> >
> > I've also tried walking the subprocess_env table in the perl handler,
> > but the value set in the C handler is not there.
>
> that's really strange. are you sure that you are not removing it in your
> application someplace? try tweaking the test tarball I mentioned bit
> by bit
> until it has the relevant logic from your code in it. I can't tell
> you the
> number of bugs I've "fixed" by trying to reproduce the bug, only to
> find I
> was the bug :)
Geoff,
So I haven't been able to get very far on the code to test this further,
but in the Eagle book I noticed this (section 9.1.4):
"subprocess_env() is only required if you need to change the environment
in a subprocess launched by a different handler or module."
So what would happen if the C module is setting it's own ENV instead of
using ap_table_set? Would that explain why I can't see the value in the
perl module using subprocess_env, but when I call void subprocess_env(),
the value suddenly appears in %ENV and the subprocess table?
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1] subprocess_env and non-mod_perl handlers
> Geoff, > So I haven't been able to get very far on the code to test this further, > but in the Eagle book I noticed this (section 9.1.4): > > "subprocess_env() is only required if you need to change the environment > in a subprocess launched by a different handler or module." what this section is talking about is the ability of mod_perl to alter the environment of other handlers, such as mod_php. in those cases, you are required to use subprocess_env. > > So what would happen if the C module is setting it's own ENV instead of > using ap_table_set? ou're thinking too hard :) there is no ENV in C-land, really. I mean, there are ways to get to perl's %ENV via C but that's not what you say you're doing. so forget about %ENV for the moment - %ENV gets set specifically my modules (mod_cgi, mod_perl, mod_php) based on the contents of the subprocess_env table and has no bearing at all if you're accessing the table directly. > Would that explain why I can't see the value in the > perl module using subprocess_env, but when I call void subprocess_env(), > the value suddenly appears in %ENV and the subprocess table? not really. but clearly you have some kind of problem. unfortunately I've never seen this before and I don't see anything in the code to suggest what your problem might be. and if I can't reproduce it I can't solve it. here are a few things to try though. first, see if changing your calls make any difference. that is, use $r->subprocess_env->get() and $r->subprocess_env->set() instead of other forms to remove the tie magic from the equation and see if that helps at all. next I would try fiddling with PerlSetupEnv to see if that has some hidden interaction with your reads. you seem to know some C, so I'd try creating a C content handler and use that to just dump the subprocess_env table. you can use mod_example.c as a guide. if you can see the variable in your own content handler but not when mod_perl is the content handler then I guess that at least verifies something. (what, I don't know :) anyway, if you are able to reproduce the problem and roll it up into the tarball I posted then I could fix whatever it is in mod_perl core that's causing you harm. HTH --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1] subprocess_env and non-mod_perl handlers
Geoffrey Young wrote on 5/4/04, 4:18 PM: > not really. but clearly you have some kind of problem. Doh! I definitely do, I think I'm it. Remember earlier when you said how in debugging you often find that you are the bug? Well, I am the bug in this case. :-) In the process of trying to figure out why I wasn't seeing anything in the subprocess_env table, I decided to take a look at the headers_in table. And there it was. Turns out that the C handler I am using (for which I have limited docs) is putting it's data into the headers_in table and not the subprocess_env table. (Insert embarrassed big red face here.) Based on everything I've read on handlers and the types of things being populated (i.e. not headers from the client) the headers_in table didn't seem to be the right place so I wasn't looking there. Sorry about that. Thanks for the help, --John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1] subprocess_env and non-mod_perl handlers
John Wittkoski wrote: > > Geoffrey Young wrote on 5/4/04, 4:18 PM: > > > not really. but clearly you have some kind of problem. > > Doh! I definitely do, I think I'm it. > > Remember earlier when you said how in debugging you often find that you > are the bug? Well, I am the bug in this case. :-) :) > > In the process of trying to figure out why I wasn't seeing anything in > the subprocess_env table, I decided to take a look at the headers_in > table. And there it was. > > Turns out that the C handler I am using (for which I have limited docs) > is putting it's data into the headers_in table and not the > subprocess_env table. (Insert embarrassed big red face here.) Based on > everything I've read on handlers and the types of things being populated > (i.e. not headers from the client) the headers_in table didn't seem to > be the right place so I wasn't looking there. > > Sorry about that. no problem at all :) at least you know a little more about both your app and some apache/mod_perl internals, so it was positive overall. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
SOAP::Lite dispatching problems
I am trying to get
my Apache server to dispatch SOAP requests per some examples on the SOAP::Lite
docs with not much success. I am running on RH9 with Apache 2.0.49,
mod_perl 1.99_13 built on perl v5.8.3 all built from source
locally.
I added the
following location directive to httpd.conf
SetHandler perl-script PerlHandler
Apache::SOAP PerlSetVar dispatch_to
"DLManager"
If have the
following as DLManager.pm in the perl INC path:
package
DLManager;
sub sayHello
{ shift; return "Hello" .
shift;}
1;
and am using the
following simple client to execute it.
#!/usr/local/bin/perl -w
use
strict;
use
SOAP::Lite;
my $Name =
shift;print "\nCalling Service\n";print
SOAP::Lite ->uri('http://localhost/DLManager') ->proxy('http://localhost/Broadline/SOAP') ->sayHello($Name) ->result;
When I execute the
client program I get
405 Method not
allowed at /hello.pl line 11
error
and no
error messages in the error or access log files.
Can someone shed
some light on this for me? I read all the docs I could find regarding
this on Google and SOAPLite.org and still have not been able to resolve the
problem.
Re: mp guide: sections -> leaks
> Thanks for the patch, Brad. But are you sure this is still the case with the > latest mp1? This thread that you've quoted is 4 years old. And it doesn't show > any code that may cause such a leak. I'm reasonable sure I got the leaks with apache 1.3.27 and mod_perl 1.27. I don't know about newer versions. I've looked again and can't find the code I used, I think it was defining a sub which was probably the leak. > >>it's not a crime, but if you're running Perl code during restart there's a > >>strong chance you'll be growing the server size. i agree 1M is bizarre > >>though. > > In which case this should probably mention: > > > +Also, be aware that sections can also cause leaks during > > +graceful restarts. See the (sub)thread: > > +http://aspn.activestate.com/ASPN/Mail/Message/modperl/304620 > > "when running some perl code"? as in 'besides using sections to do > dynamic configuration'? I took the "if you're running Perl code during restart" to include dynamic configuration code. I don't really understand the process so I'll defer to you. I'd just like to see sections mentioned as a possible culprit. Brad -- Ikuno Oribe said, "If a retainer will just think about what he is to do for the day at hand, he will be able to do anything. If it is a single day's work, one should be able to put up with it. Tomorrow, too, is but another single day."-- Hagakure http://bereft.net/hagakure/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: SOAP::Lite dispatching problems
> When I execute the client program I get
> 405 Method not allowed at /hello.pl line 11
> error and no error messages in the error or access log files.
> Can someone shed some light on this for me? I read all the docs I could
> find regarding this on Google and SOAPLite.org and still have not been able
> to resolve the problem.
this really isn't a SOAP::Lite support forum, so you might want to try the
soaplite list (still on yahoo?) instead.
in any case, it's been a while since I played with SOAP::Lite, but here is
how I used to debug things, which I'm pretty sure I found in the docs:
use SOAP::Lite
+autodispatch =>
uri => 'http://localhost/Foo/SOAP',
proxy => 'http://localhost/Foo',
on_fault => sub {
my($soap, $res) = @_;
die ref $res ? $res->faultstring :
$res, " ", $soap->transport->status, "\n";
},
on_debug => [EMAIL PROTECTED];
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp guide: sections -> leaks
Brad Bowman wrote: Thanks for the patch, Brad. But are you sure this is still the case with the latest mp1? This thread that you've quoted is 4 years old. And it doesn't show any code that may cause such a leak. I'm reasonable sure I got the leaks with apache 1.3.27 and mod_perl 1.27. I don't know about newer versions. I've looked again and can't find the code I used, I think it was defining a sub which was probably the leak. it's not a crime, but if you're running Perl code during restart there's a strong chance you'll be growing the server size. i agree 1M is bizarre though. In which case this should probably mention: +Also, be aware that sections can also cause leaks during +graceful restarts. See the (sub)thread: +http://aspn.activestate.com/ASPN/Mail/Message/modperl/304620 "when running some perl code"? as in 'besides using sections to do dynamic configuration'? I took the "if you're running Perl code during restart" to include dynamic configuration code. I don't really understand the process so I'll defer to you. I'd just like to see sections mentioned as a possible culprit. Well, I hoped that someone will tune in and share a code sample, but as noone did (at least yet) I've just committed your original patch, warning about the possibility of the leak. Thank you, Brad. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
QA positions, Mountain View, CA
Hello, We have several open positions at Tellme. Tellme's web backend environment is mainly mod_perl based, involving externally visible, traditional web applications, as well as internal VoiceXML applications and XML data feeds. Tellme systems use HTTP and XML extensively as a generic data-passing mechanism, and webservers are involved in everything from dynamic configuration for our hundreds of production machines, to integration with customer billing systems. Here is the job description: The Client Success Quality Assurance Team At Tellme Networks is seeking two highly-motivated individuals for the following full-time positions: Intermediate QA Engineer and Senior QA Engineer. Both positions will be responsible for developing test plans based on design specifications, executing test plans, and also writing and maintaining test scripts in PERL or a similar high-level language. Additionally, they will contribute towards the success of client projects by coordinating with project team members -- including integration architects, developers, and project managers -- in order to prevent, report, and resolve product defects. The candidate for both the intermediate and senior QA positions must possess the following qualifications: - BS Computer Science, or an equivalent combination of education and experience - Strong communication skills (written and verbal) - Proficient knowledge of Windows and UNIX - Working knowledge of C/C++, HTML, XML, PERL - Experience with automated testing and knowledge of performance testing (SilkPerformer a plus) - Some knowledge of databases (Oracle, mySQL) The Intermediate QA Engineer should have a minimum of 2-3 years of QA experience, whereas the Senior QA Engineer should have 5+ years of QA experience. Additionally, the Senior QA Engineer should have the ability to independently lead QA with a larger scope in medium to large-scale projects. For more information on Tellme, visit the Tellme corporate website at http://www.tellme.com/. To get an idea of some of the possibilities of our technology, call our free voice portal at 1-800-555-TELL or get toll free directory assistance by dialing 1-800-555-1212. If you have any questions, you can e-mail me at [EMAIL PROTECTED] -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: SOAP::Lite dispatching problems
On Tue, 4 May 2004, Geoffrey Young wrote:
> > When I execute the client program I get 405 Method not
> > allowed at /hello.pl line 11 error and no error messages
> > in the error or access log files. Can someone shed some
> > light on this for me? I read all the docs I could find
> > regarding this on Google and SOAPLite.org and still have
> > not been able to resolve the problem.
>
> this really isn't a SOAP::Lite support forum, so you might
> want to try the soaplite list (still on yahoo?) instead.
>
> in any case, it's been a while since I played with
> SOAP::Lite, but here is how I used to debug things, which
> I'm pretty sure I found in the docs:
>
> use SOAP::Lite
> +autodispatch =>
> uri => 'http://localhost/Foo/SOAP',
> proxy => 'http://localhost/Foo',
> on_fault => sub {
> my($soap, $res) = @_;
> die ref $res ? $res->faultstring :
> $res, " ", $soap->transport->status, "\n";
> },
> on_debug => [EMAIL PROTECTED];
As well as that for debugging, also check the soaplite
mailing list archives, as Geoff suggests - I believe that
some patches to SOAP::Lite (specifically, in
SOAP::Transport::HTTP) are needed to work with mod_perl 2.
--
best regards,
randy kobes
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
