Re: Modperl/Apache deficiencies... Memory usage.
Justin,
On Tue, Apr 25, 2000 at 11:26:00PM -0400, [EMAIL PROTECTED] wrote:
> On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > > It is very memory inneffecient basically. Each process of apache has
> > > it's registry which holds the compiled perl scripts in..., a copy of
> > > each for each process. This has become an issue for one of the
> > > companies that I work for, and I noted from monitoring the list that
> > > some people have apache processes that are upwards of 25Megs, which is
> > > frankly ridiculous.
> >
>
> Originally I thought this as well.. but, using mod_rewrite, the ratio
> of heavy to light processes can be very high.. some solid figures here:
> our site (dslreports) now handles 200,000 pages a day, every single one
> of them is dynamically generated.. at peak this is 10-20 modperl pages
> a second.. to handle this, we have httpd modperl with MIN, MAX
> and LIMIT of just 8(!) modperl processes, 2 php httpds (just for true type
> font rendering ;-) and as many front-end httpds (mod_rewrite and mod_proxy)
> as required (usually about 100 but can be 200-300 at times). There is
> almost never all 8 modperls running at one time.. even long pages fit
> in the buffers between back end, mod_proxy, and front end meaning its
> hard to catch mod perl in the act of actually servicing requests.
Yes... mod_proxy is the "right way" to really get any sort of serious
stuff hapening in terms of speed. With mod_proxy you really only need
a few mod_perl processes because no longer is the mod_perl ("heavy")
apache process i/o bound. It's now CPU bound. (or should be under
heavy load) Sounds like your ratio is pretty good. (modperl/
mod_proxy) I'd be willing to gamble you could have even less
less mod_perl processes :-).., because they *should* be completely CPU
bound... so really under a "theoretical" machine the optimum number
would be as many processors as you had. But since mod_proxy/mod_perl
communicate through a socket as opposed to shared memory, there is
still a little i/o action. (Which is something I'm thinking about
working on too in mod_proxy..., in local mode allow for more efficient
data transfer methods than sockets) The closer you get to the number
of processors the less context switching involved... although sounds
like you have lots of other stuff running on this box... so this
becomes less of an issue.
> So I find this setup very stable and very flexible .. and would not swap it
> for a pool of interpreters, or a multi-threaded server for all the tea
> in china .. because I dont think either of those models (elegant though
> they may sound, and absolutely the right direction) will be as stable
> for some considerable time.
Hehe... and it is for this exact reason that the actual httpd serving
mechanism hasn't changed much since... well, they started preforking?
Geez... how long ago was that?..., I guess when they started patching
NCSA... so a LONG time ago. I really think it's time... cross
platform is great, but don't hold back other platforms functionality
just to keep the number of macros in the source down... I mean really.
Its sort of a chicken and the egg scenario..., POSIX.4 was put
together some time ago. But it was only implemented in Linux in
2.3.28 or later (or so), well it was in some earlier version, but had
some sort of bug. I think FreeBSD has it too. But theres no pressure
on anyone else to do anything about it because theres no apps. But
theres no apps because theres no OS support... :-)... I hate those
sorts of situations. Who knows when windows will get it? Maybe
Windows 3k.
(I should note, there have been lots of "tweaks" along the way, but
nothing essentially different in concept)
Thanks,
Shane.
>
> -Justin
Re: Modperl/Apache deficiencies... Memory usage.
Doug & modperlers... > however, padlists are not shared. as i mentioned, i'd like to look at > using your "garbage collector" for 2.0. if it could run in it's own > thread and examine the padlists of idle interpreters, it could be big win. > i wouldn't want it to release all allocations in the padlist by default. > maybe be configurable to only release things of a certain size. what i > would personally like to see is one that just reports anything that's > larger than X size, so i can fix the Perl code not copy large chunks of > data, and/or figure out how to make large chunks of data shared between > interpreters. i kinda started this with the B::Size hooks in > Apache::Status, but you have to dig around the symbol table to find how > big things are, there's no overall reporting mechanism. Let me know when you want the garbage collector. I'll re-write it in apache style, and add some debugging stuff. I figure there should be two pieces. One that analyzes the packages that are running, the other that actually kills off variables. This could be very usefull for admins that want to analyze what those huge processes really are. Are they all code?, are they stack variables? A reporting module would be really cool, and it would answer a lot of questions that I have. So you're right..., I think that's the first piece that should be implemented. I just need to re-write it for multiple levels of recursion (Present version only scans the first level). Basically re-hack it to exclude actual cleaning, and just reporting, and maybe as a secondary module a cleaner. Something like use Apache::Cleaner..., in a fully threaded apache only one thread would be needed. In a process enviro... arg!... I don't want to think about that right now... I know the answer but I just hate to say it. (Maybe like Apache::Memory::Cleaner, and Apache::Memory::Reporter?... how does that sound? We'd need some mutexes on the Registry so that the cleaner doesn't end up cleaning a running Registry Script ... should this extend to Handlers?) > > > One of my concerns is that maybe the apache module API is simply too > > complex to pull something like this off. I don't know, but it seems > > like it should be able to handle something like this. > > if you need a model where the Perl engine is in a different process > than Apache, that should be implemented with FastCGI or something else. > the overhead of passing the request_rec (and everything it points to) > between processes for all of the various phases (so mod_perl could > still everything it can today) would be a nightmare. I really don't need such a model at this time. However I was thinking about it..., and aside from the point that Stas brought up, I think this would be an interesting avenue to look through... that's essentially how mato_perl works. The crazy idea that I forwarded to Stas was something like this: The problem with having one thread is network reads. This is actually a really big issue all in all. However, if it were possible to override the "read" and "write" functions that would sort of "freeze" execution, and put a lock on this Apache registry entry (and make a unlocked copy BTW), and transfer it to another thread whos only job was read/write through a sigqueue interface... that would be REALLY cool for performance/memory consumption. Much less context switching overhead, and drastically reduced memory overhead. The problem is that who in their right mind has time for this sort of thing? (:->) I was thinking of implementing the writing of mod_proxy like this..., after considering it fully though, I think it would be even better to write a generalized module that could stream bits to clients, and use it as a plug in for any module that doesn't want to waste time streaming out to a 28.8k connection. Anyhow... this is my present obsession, and I'm hoping to have a beta patch to mod_proxy in about a month. But if I were to re-implement it as a generic apache module, and give it some state context, and the ability to read and write, it could be very very usefull for nearly anything for apache. (Obviously sigqueue's aren't implemented on every platform, so either poll(), or select would take it's place in these scenarios... still more efficient than having a "heavy" mod perl enabled server sending data to 28.8k client) Anyhow... thanks Doug, Shane. (Man, you've got a good memory... that was over two months ago I brought up the GC)
Re: newbie help installation problems modperl/apache
At 08:24 PM 4/25/00 -0600, you wrote: >You're reading the right INSTALL doc but make sure you follow the >directions un the heading "the flexible way". Not the other one. Also go >back and reread all the stuff on compiling and configuring on >perl.apache.org/guide too. Yup, I have been following "the flexible way". Your instructions follow this, and this is what I followed. However, you've heard my results. There are a few updates however, when I copied the apache httpd module to /usr/sbin, mod_perl's configuration step worked without the apxs warning, make and make install took longer, and Perlsetenv & perlhandler commands worked. hello.world works. This tells me that either there is a problem with mod_perl's Makefile.PL, or (more likely) there is something leftover from the original apache/modperl rpms, which is causing havoc with mod_perl's Makefile.PL, and screwing up the install. Even though hello world is working, the make test is still failing as it was before. Further, there is a libperl.a in apache/src/modules/. >It sounds like you on a RH Linux box that has (or had) the rpm Apache >distro installed. Make it go away. It's a bad thing IMHO. Yup. I had done the rpm -e apache mod_perl. I didnt see any parts left over. I dont have the option of reinstalling the os. I had to do the apache source because I needed suexec, and you cant get there from the rpms. >You shouldn't even be at item 4 unless you get past make test with no >errors. (Don't get so excited I know it's cool but get it working first.) > make test fails, but the other stuff works. go figure. >Here's what I do to build Apache/mod_perl on my servers (and I haven't had >a problem build in really long time, knock on wood). > >cd ../apache_1.3.12 > >./configure --prefix=/opt/www/httpd \ >--activate-module=src/modules/perl/libperl.a \ >--enable-module=rewrite \ >--enable-module=mmap_static \ >--enable-module=log_referer \ >--enable-module=log_agent > when trying to get apache to work (before integrating mod_perl), I couldnt get functions to work correctly without --enable-module=most and --enable-shared=max. I didnt test combinations of these settings. without this, none of the loadmodule/addmodule directives in the httpd.conf worked. On the various lists to which I tried to get help, the silence was deafening. I might try to play with these. What does your httpd.conf look like? Loadmodule/Addmodule? I do a lot of webhosting, with a ton of namevirtualhosts, cgi-bins, and .htaccess files. >Jeff Beard > Thanks. jr John Riehl IBucks, Inc. Beverly Hills, Ca.
design question
I am trying to implement a cross platform auth scheme whereby users log into a system running in a microsoft environment. Then, when they want to check their e-mail, they click a link in the form of: mail.isoftcorp.com/auth?k= the key sequence is determined when they log into the main site and it is databased. then, they hit my server and I will take the key sequence and query the databse: 1) The database returns foo, I deny the request (this I can eaily do) 2) The database returns bar, I rewirte the request into a post. The handler would rerite the request and then turn it back over to apache for further processing: my new request would be in thr form of: $request=HTTP::Request->new(POST=>'http://mail.isoftcotp.com/index.pl', [var1=>'hojo',var2=>'val2']); #where val1 and val2 are from the DB However, I do not know how to rewirte the request in this way and use it in a handler. What would be the proper way to rewrite the request? Which handler should I use? If I need to provide any more info, fell free to ask.
ANNOUNCE: HTML::Embperl 1.3b3
The URL
ftp://ftp.dev.ecos.de/pub/perl/embperl/HTML-Embperl-1.3b3.tar.gz
has entered CPAN as
file: $CPAN/authors/id/GRICHTER/HTML-Embperl-1.3b3.tar.gz
size: 272444 bytes
md5: a0a28868e85094f7d52f00fa8d046298
Changes since 1.3b2:
- Fixed SIGSEGV which occurs in cleanup with Perl 5.6. Spotted by
Aaron Johnson.
- Changed make test so it works correctly with new error messages of
Perl 5.6.
- Fixed a bug that Execute will always fail when $@ was set before.
Patch from Francis J. Lacoste.
- Changed test so it accpects charset in Content-Type header from
Apache 1.3.12
- The outputfile parameter now also works when running under
mod_perl. Spotted by Ilia Lobsanov.
- Makefile.PL warns if you build with a DSO mod_perl < 1.22
- make test checks that test files are readable by Apache.
- Applied a patch from Jens-Uwe Magner to make Embperl work
with mod_perl 1.22 on AIX. We now require mod_perl 1.22,
but I should now work as DSO and staticly linked.
- Applied a patch from Francis J. Lacoste that makes sure
that when a package name is given the file is always compiled
into this package. Note: This means that if you specify a
packagename and the packagename differs from request to
request, the page is compiled for every package and therfore
consuming memory on every request.
- Added EMBPERL_SESSION_HANDLER_CLASS which allows you to overwrite
Embperl defaults session handling. Idea form Barrie Slaymaker.
- Added EmbperlLogo.gif to the distribution, which contains
"Powered by Embperl".
- Added Patch from Randy Kobes that makes Embperl compile with
Apache 1.3.12 and Perl 5.6 on Win32.
- Removed some -w warnings form EmbperlObject
- Added tests for EmbperlObject
- Fixed a SIGSEGV that occured when Embperl found [*] inside
a page. Spotted by Barrie Slaymaker.
- Added epchar.c.min which contains translation tables which
let's all chars above 128 untouched. This is usefull for
processing two byte charsets. Patch from Sangmook Yi.
- The searchpath (EMBPERL_PATH) now uses semikolons (';') instead
of colons (':') to avoid problems with Windows drive letters.
Colons still work on Unix.
-
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 925151
WWW:http://www.ecos.de Fax: +49 6133 925152
-
Re: Modperl/Apache deficiencies... Memory usage.
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote: > > > It is very memory inneffecient basically. Each process of apache has > > it's registry which holds the compiled perl scripts in..., a copy of > > each for each process. This has become an issue for one of the > > companies that I work for, and I noted from monitoring the list that > > some people have apache processes that are upwards of 25Megs, which is > > frankly ridiculous. > Originally I thought this as well.. but, using mod_rewrite, the ratio of heavy to light processes can be very high.. some solid figures here: our site (dslreports) now handles 200,000 pages a day, every single one of them is dynamically generated.. at peak this is 10-20 modperl pages a second.. to handle this, we have httpd modperl with MIN, MAX and LIMIT of just 8(!) modperl processes, 2 php httpds (just for true type font rendering ;-) and as many front-end httpds (mod_rewrite and mod_proxy) as required (usually about 100 but can be 200-300 at times). There is almost never all 8 modperls running at one time.. even long pages fit in the buffers between back end, mod_proxy, and front end meaning its hard to catch mod perl in the act of actually servicing requests. On the same box is mysql (40-60 daemons), constant mail handling, various other custom perl daemons and utilities, MRTG monitoring of 100s of IP addresses, a busy ultimate bulletin board (plain cgi - ugh), development and testing as well sometimes. This is all handled by two 450mhz processors and 1gig of memory, no swapping, half of the memory ends up being used by linux for disk caching.. modperl uses up about 256mb I suppose. With that much traffic, memory leaks, and the odd SQL query that reads too much, the modperl processes grow slowly to about 40mb each, but get reborn, every 1000 requests, at 28mb again. The load average hovers around 5.0 I read today drkoop (while going broke) now does 600k pages per day.. I bet they have a couple of million bucks worth of solaris, oracle and IIS, serving out mainly static content? whats the price/performance problem with modperl again? So I find this setup very stable and very flexible .. and would not swap it for a pool of interpreters, or a multi-threaded server for all the tea in china .. because I dont think either of those models (elegant though they may sound, and absolutely the right direction) will be as stable for some considerable time. -Justin
RE: ANNOUNCE: Apache::AuthCookie 2.007
[EMAIL PROTECTED] (Gerald Richter) wrote: >Hi Ken, > >the patch I send you for overwriting the login_form seems not to be in >2.007. > >Are there any reason for this or did you just forget it? Hi Gerald, Actually, neither - it's just that I haven't gotten to it yet. The changes I put in 2.007 come from requests/patches people submitted before you. =) Your patch looks good, but I haven't had a chance to look closely. I hope to get it in there soon in some form.
Re: Modperl/Apache deficiencies... Memory usage.
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote: > Modperlers..., > > I'd like to start a discussion about the deficiences in Apache/modperl > and get you feedback with regard to this issue. The problem as I see > it is that the process model that Apache uses is very hard on modperl. mod_perl-2.0/apache-2.0 should solve this (fingers crossed :) > It is very memory inneffecient basically. Each process of apache has > it's registry which holds the compiled perl scripts in..., a copy of > each for each process. This has become an issue for one of the > companies that I work for, and I noted from monitoring the list that > some people have apache processes that are upwards of 25Megs, which is > frankly ridiculous. with 2.0, the syntax tree is shared (at the Perl level) however, padlists are not shared. as i mentioned, i'd like to look at using your "garbage collector" for 2.0. if it could run in it's own thread and examine the padlists of idle interpreters, it could be big win. i wouldn't want it to release all allocations in the padlist by default. maybe be configurable to only release things of a certain size. what i would personally like to see is one that just reports anything that's larger than X size, so i can fix the Perl code not copy large chunks of data, and/or figure out how to make large chunks of data shared between interpreters. i kinda started this with the B::Size hooks in Apache::Status, but you have to dig around the symbol table to find how big things are, there's no overall reporting mechanism. > One of my concerns is that maybe the apache module API is simply too > complex to pull something like this off. I don't know, but it seems > like it should be able to handle something like this. if you need a model where the Perl engine is in a different process than Apache, that should be implemented with FastCGI or something else. the overhead of passing the request_rec (and everything it points to) between processes for all of the various phases (so mod_perl could still everything it can today) would be a nightmare.
Re: Deep recursion on subroutine "Apache::Constants::AUTOLOAD"
On Tue, 25 Apr 2000, Martin Lichtin wrote: > Doug MacEachern wrote: > > > Anyone understand why > > > perl -we 'use Apache::Constants; Apache::Constants::OK();' > > > causes this problem? > > > > what version of mod_perl are you using? ' > > mod_perl 1.21, perl 5.00503 ok, well, i don't understand why you're getting this error on the command line, but Apache::Constants only works inside httpd anyhow. are you having a problem using it inside httpd?
Re: Deep Recursion with File::Copy
On Tue, 25 Apr 2000, Jeremy Blumenfeld wrote: > Hi. > We are running Server Version: Apache/1.3.9 (Unix) mod_perl/1.21 on a > Linux system. > Having problems with a "Deep Recursion" when using the copy method of > File::Copy. my guess is that you're using Perl 5.005_03 and have PerlFreshRestart On perl 5.6.0 fixes File::Copy so it can be reloaded (see Changes entry below). either turn FreshRestart Off or update File::Copy to 5.6.0's version [ 4753] By: gsar on 2000/01/05 06:48:22 Log: From: [EMAIL PROTECTED] (Andreas J. Koenig) Date: 03 Jan 2000 21:56:02 +0100 Message-ID: <[EMAIL PROTECTED]> Subject: Reloading File::Copy Branch: perl ! Changes lib/File/Copy.pm t/lib/filecopy.t
RE: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Eric Cholet wrote:
> mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns
> on threading and multiplicity.
just to be clear, as you mention below, -Dusetheads isn't required for
mod_perl-2.0, but strongly suggested if you use an mpm other than prefork :)
and i wouldn't say -Dusethreads "turns on threading", it simply makes the
Perl runtime re-entrant (as explained in an earlier message)
> The biggest hurdle I've faced until now is
> that DBI won't build with this threaded perl. Hopefully DBI will be updated
> since the latest version is from july 99.
it compiles with the patch below, not sure if it actually works though :)
> This is for using Apache 2.0's pthread MPM, of course you can build perl
> 5.6 non threaded and use apache 2.0's prefork model but then it's not
> as exciting :-)
maybe not as exciting, but still very important, the 1.3.x model works
quite well for many people, so mod_perl-2.0 will continue to support it.
--- DBI.xs~ Sun Jul 11 19:04:27 1999
+++ DBI.xs Tue Apr 25 19:05:40 2000
@@ -9,6 +9,13 @@
#include "DBIXS.h" /* DBI public interface for DBD's written in C */
+#ifndef pTHX_
+#define aTHXo_
+#define CopFILEGV(cop) cop->cop_filegv
+#define CopLINE(cop) cop->cop_line
+#define get_sv perl_get_sv
+#endif
+
#define MY_VERSION "DBI(" XS_VERSION ")"
#if (defined USE_THREADS || defined PERL_CAPI || defined PERL_OBJECT)
@@ -112,7 +119,7 @@
# if (PATCHLEVEL == 4) && (SUBVERSION < 68)
# define dPERINTERP_SV \
-SV *perinterp_sv = perl_get_sv(MY_VERSION, FALSE)
+SV *perinterp_sv = get_sv(MY_VERSION, FALSE)
# else
# define dPERINTERP_SV \
SV *perinterp_sv = *hv_fetch(PL_modglobal, MY_VERSION, \
@@ -121,7 +128,7 @@
# define dPERINTERP_PTR(T,name)\
T name = (T)(perinterp_sv && SvIOK(perinterp_sv) \
- ? SvIVX(perinterp_sv) : NULL)
+ ? (T)SvIVX(perinterp_sv) : NULL)
# define dPERINTERP\
dPERINTERP_SV; dPERINTERP_PTR(PERINTERP_t *, PERINTERP)
# define INIT_PERINTERP \
@@ -189,13 +196,13 @@
DBIS->size= sizeof(*DBIS);
DBIS->xs_version = DBIXS_VERSION;
/* publish address of dbistate so dynaloaded DBD's can find it */
-sv_setiv(perl_get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
+sv_setiv(get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
DBISTATE_INIT; /* check DBD code to set DBIS from DBISTATE_PERLNAME*/
DBIS->logfp= stderr;
DBIS->debug= 0;
-DBIS->neatsvpvlen = perl_get_sv("DBI::neat_maxlen", GV_ADDMULTI);
+DBIS->neatsvpvlen = get_sv("DBI::neat_maxlen", GV_ADDMULTI);
sv_setiv(DBIS->neatsvpvlen, 400);
/* store some function pointers so DBD's can call our functions*/
DBIS->getcom= dbih_getcom;
@@ -613,7 +620,7 @@
if (imp_size == 0) {
/* get size of structure to allocate for common and imp specific data */
char *imp_size_name = mkvname(imp_stash, "imp_data_size", 0);
- imp_size = SvIV(perl_get_sv(imp_size_name, 0x05));
+ imp_size = SvIV(get_sv(imp_size_name, 0x05));
if (imp_size == 0)
imp_size = g_imp_maxsize + 64;
}
@@ -1450,16 +1457,16 @@
fprintf(logfp," during global destruction.");
return;
}
-if (!curcop->cop_line) {
+if (!CopLINE(curcop)) {
fprintf(logfp," at unknown location!");
return;
}
-file = SvPV(GvSV(curcop->cop_filegv), len);
+file = SvPV(GvSV(CopFILEGV(curcop)), len);
if (trace_level<=4) {
if ( (sep=strrchr(file,'/')) || (sep=strrchr(file,'\\')))
file = sep+1;
}
-fprintf(logfp," at %s line %ld.", file, (long)curcop->cop_line);
+fprintf(logfp," at %s line %ld.", file, (long)CopLINE(curcop));
}
@@ -1751,7 +1758,7 @@
*/
I32 markix = TOPMARK;
CV *xscv = GvCV(imp_msv);
- (void)(*CvXSUB(xscv))(xscv);/* Call the C code directly */
+ (void)(*CvXSUB(xscv))(aTHXo_ xscv); /* Call the C code directly */
if (gimme == G_SCALAR) {/* Enforce sanity in scalar context */
if (++markix != stack_sp - stack_base ) {
@@ -2130,7 +2137,7 @@
Fflush(DBILOGFP);
}
DBIS->debug = level;
- sv_setiv(perl_get_sv("DBI::dbi_debug",0x5), level);
+ sv_setiv(get_sv("DBI::dbi_debug",0x5), level);
}
}
OUTPUT:
@@ -2226,7 +2233,7 @@
}
if (type == '$') { /* lookup scalar variable in implementors stash */
char *vname = mkvname(DBIc_IMP_STASH(imp_xxh), meth, 0);
- SV *vsv = perl_get_sv(vname, 1);
+ SV *vsv = get_sv(vname, 1);
if (trace)
fprintf(DBILOGFP,"<- %s = %s\n", vname, neatsvpv(vsv,0));
ST(0) = sv_mortalcopy(vsv);
RE: mod_perl 2.x/perl 5.6.x ?
On Sun, 23 Apr 2000, Gunther Birznieks wrote: > I agree... but to some degree I hope this has been done for many of the > major modules and the major DBI modules (eg DBD sybase)... as they ended up > having to work on ActiveState's PerlEx which uses a similar model. In a > way, PerlEx's model has been a test for mod_perl 2.0. indeed. PerlEx uses PERL_OBJECT, which is similar in concept to USE_ITHREADS. we all owe a great deal of thanks to ActiveState for sponsoring Gurusamy Sarathy's work on 5.6.0. without the USE_ITHREADS implementation, mod_perl would be next to useless with threaded apache-2.0
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Leslie Mikesell wrote: > So, does that still leave mod_perl serializing access until > everything is rewritten to be thread-safe? no, -Dusethreads with 5.6.0 makes the Perl runtime (aka PerlInterpreter), re-entrant. all of Perl's internal globals (symbol table, stacks, etc.) become part of the PerlInterpreter structure, each interpreter clone has it's own copy of any writeable data (symbol table, stacks, etc.) the syntax tree is shared. this makes it possible to concurrently call subroutines in different threads, which was not possible with 5.005_03. this doesn't solve the problem of xs modules or c libraries that are not thread-safe, we'll have to fix any trouble makers as they pop up.
Re: mod_perl-1.99_01-dev
On Fri, 21 Apr 2000, Greg Cope wrote:
> Does this mean that we {will|may} be able to use the interpreter pool to
> set up X Perl interpreters (say 20 to service dynamic handlers) with Z
> apache (say 60 to handle static + dynamic content - assuming the dynamic
> content is passed to the Perl interpreters) children, and hence have
> significant memory savings as we can avoid (in some cases) the light / heavy
> httpd model ?
yes, exactly.
Re: do "file" -- does NOTHING
this is either something 5.6.0 broke, or nobody has been using
Apache->httpd_conf, patch below fixes.
the MMN check isn't needed anymore anyhow, we've given up supporting older
versions of Apache long ago.
Index: Apache/Apache.pm
===
RCS file: /home/cvs/modperl/Apache/Apache.pm,v
retrieving revision 1.46
diff -u -r1.46 Apache.pm
--- Apache/Apache.pm2000/04/05 04:55:55 1.46
+++ Apache/Apache.pm2000/04/26 01:06:28
@@ -24,16 +24,14 @@
__PACKAGE__->mod_perl::boot($VERSION);
}
-if($ENV{MOD_PERL} && perl_hook("Sections")) {
+BEGIN {
*Apache::ReadConfig:: = \%ApacheReadConfig::;
+}
-if(Apache::Constants::MODULE_MAGIC_NUMBER() >= 19971026) {
- *Apache::httpd_conf = sub {
- shift;
- push @Apache::ReadConfig::PerlConfig,
- map "$_\n", @_;
- };
-}
+sub httpd_conf {
+shift;
+push @Apache::ReadConfig::PerlConfig,
+ map "$_\n", @_;
}
sub parse_args {
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
On 20 Apr 2000, Randal L. Schwartz wrote: > > "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes: > > Doug> why all the globals?? symbol table lookups are much slower than > Doug> lexicals. > > If I recall, the word lately is that they're much closer than they were. i take it back, the symbol table lookups for globals are done at compile time, 5.x has always done that, i think. by the looks of: perl -MO=Terse -e 'my $lex = 1; our $ogv = 1; $gv = 1' they still behave the same at runtime, though what happens during compile time might be different. > But lexicals are still "cleaner", if I recall. indeed.
Re: Passing POST Data to a SubRequest
On Thu, 20 Apr 2000, Chris D'Annunzio wrote: > > > > Is there a way to pass data into a SubRequest using the post method? > > > > no, you'll need to use GET and $r->args > > > > which can be made transparent with the module below, provided your code > > can deal with post POST and GET requests. > > That works great if the Content-Type of the POST is > application/x-www-form-urlencoded. Is there a way to deal with other > Content-Types like multipart/form-data? for something like that, you'd be better off using the $r->pnotes table to pass a CGI.pm or Apache::Request object to the subrequest. Apache::RequestNotes on cpan might be useful to you.
Re: Modperl/Apache deficiencies... Memory usage.
On Mon, 17 Apr 2000, Perrin Harkins wrote:
> What I know about Perl internals could fit on the head of a pin, but
> this strikes me as a very odd statement. If the garbage collector is
> never used, why do my lexical variables go out of scope and get
> destroyed? There are mod_perl packages like Apache::Session that
> absolutely depend on garbage collection of lexical variables to work.
> Are you saying that destroying the variables and actually reclaiming the
> memory are separate, and only the first is happening?
excactly, lexicals "go out-of-scope", but most of the memory allocations
are not freed unless you explicitly undef. e.g.:
sub foo {
my $string = shift;
print $string;
}
foo("hello world");
after the subroutine is called, the SvPVX field of $string hangs onto the
allocated length("hello world") + 1, unless you undef $string;
this is an optimization, Perl assumes if you've allocated for a variable
once, you'll need to do it again, making the second assignment+ much
cheaper. the elements of lexical arrays and hashes are released (well,
the refcnt is decremented, which triggers free if the refcnt was 1) when
one goes of-of-scope, but the size of the array/hash remains for the same
reasons. this is another reason it's always best to pass a reference when
possible, for $strings, @arrays and %hashes, to avoid these copies.
a the B::Size B::LexInfo packages on cpan were written to illustrate this,
though one or both needs fixing for 5.6.0, which i'll get to soon.
Re: $r->get_handlers bug/oversight?
On Tue, 25 Apr 2000, Geoffrey Young wrote:
> Hi all...
>
> I've noticed that get_handlers() will return the enabled handlers
> for a PerlPostReadRequestHandler, but not when it is specified as a
> PerlInitHandler (either by calling
> $r->get_handlers('PerlPostReadRequestHandler') or
> $r->get_handlers('PerlInitHandler'). It is the same with
> PerlHeaderParserHandler. An oversight?
>
> Also, I can't get anything for PerlCleanupHandlers, which kinda
> makes sense, since Cleanup isn't really a phase, per se (at least according
> to the book). Does it make sense to add this to get_handlers() as well?
oversight. neither CleanupHandler nor InitHandlers is in the
handler_table in Apache.xs. probably because those directives were added
after get/set handlers was implemented, and the table was never updated.
i'll see about fixing that.
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Jeffrey W. Baker wrote:
> The origin of these inconsistencies has, I think, been the years-long
> development of both mod_perl and Apache 1.x. Some headers may have their
> own accessors because they need to tweak something in the Apache core when
> they get set.
i'll take blame for the poor docs, certainly something that will be fixed
with 2.0. as for the api, i think mod_perl is already consistent with
Apache's, with a few tweaks here and there to make things more Perlish.
if you think Apache's api is inconsistent, then let's fix it there, i
don't want to move too far away it in mod_perl. while i agree it's kinda
awkward that certain headers have their own get/set functions, rather than
dropping/getting them raw into the headers_{in,out} tables, it's only done
where needed. e.g. $r->set_content_length() not only adds the header to
r->headers_out, it updates another field in the request_rec (r->clength)
i don't want to add get/set method for all possible headers_{in,out}, that
would bloat things. of course, you could implement an Apache::Headers
modules that does this, but i don't want to add too many methods that the
Apache api doesn't implement in the mod_perl "core".
Apache.xs is a kitchen sink, expect to see it broken out into smaller
modules (ala Apache::File, Apache::Log), that add methods into the
Apache:: namespace.
before any of the 2.0 code is written that glues into the request_rec and
friends, i plan to writeup a layout of the classes/methods and where
everything lives. we can sort out any issues then before the api is
implemented.
Re: PerlHandler stopped working???
> I do now - just uploaded a new version. It's still not correct though - a
> proper fix would have to pull SetHandler out of mod_mime altogether, I
you'd still have the same problem, Apache stops calling type handlers
after the first one returns OK. besides, you can apply the SetHandler
config in your TypeHandler by using a subrequest, no need to pull it out
of mod_mime.
> I guess one important question is - why do we have to call SetHandler for
> PerlHandlers and not for any of the other handler phases. For all the
> other phases Apache/mod_perl automatically figures out if there's a
> handler installed and either runs perl code, or lets apache do its
> work. Why can't PerlHandler do the same? (as you can tell - I haven't dug
> into the internals of this - but I am curious).
because Apache dispatches response handlers based on the modules'
handler_rec (part of the module structure). the key Apache uses to do
that lookup is r->handler, which if NULL, falls back to r->content_type.
> Right. So what's the point of PerlTypeHandler again?... ;-) Seriously
> though - Apache::MimeXML is the only PerlTypeHandler, as far as a quick
> search reveals, apart from your examples in the book. So maybe it would be
> worth investigating this further.
there's nothing to investigate, Apache is working as it is designed.
if you feel this is a design flaw, the the issue should be raise on
[EMAIL PROTECTED] list.
as i mentioned above, alternative to the FixupHandler workaround, if your
TypeHandler wants to let mod_mime contribute, it can run a subrequest and
copy the $subr->{handler,content_type} as you see fit.
> A fixup handler is an interesting solution... but can I stack
> FixupHandlers? (I run most of my mod_perl code from a FixupHandler).
yes.
> Also, you didn't pick up on something I sent to the list in another
> thread... I have code that goes:
>
> if ($r->current_callback eq 'PerlFixupHandler') {
> $r->push_handlers('PerlHandler', \&code);
> }
> else {
> &code($r);
> }
>
> so that I can install the module as either a fixup or a PerlHandler. The
> fixup installed version is 4 times slower than calling the function
> directly - is that to be expected? (we're talking 20 requests/sec vs 80
> here - a huge difference).
i wouldn't expect that much of a difference. i'll look into it.
Re: write a filefrom a navigator
benoit bordigoni wrote: > > Hello, > I'm a little perl developper, in a little french enterprise, (hexaflux). > I make my period of training and I use an apache server 1.3x. I've got some > problem with my server. It does not allow me to execute system commands in > perl : > "system (chmod 755 file.pl)" and > "open (MYFILE, file.pl ". I > f I execute my script by executing the following command : > /usr/bin/perl /home/httpd/cgi-bin/script.pl, > the file, "file.pl" is created and file.pl has the good permissions and it > works! But if it is executed from the navigator it doesn't works!! I think > that the permisions on the server are not good. Based on the snippet you posted, you would want to make sure that /home/httpd/cgi-bin/script.pl is writable by whatever user the seb server runs as (usually nobody). Be warned that you have to be careful with world writable directories! Hope this helps. On a unix box you would type the following (based on your example): chmod o+w /home/httpd/cgi-bin -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: gensym()
On 4/24/00 10:06 AM, Randal L. Schwartz wrote:
>> "Matt" == Matt Sergeant <[EMAIL PROTECTED]> writes:
>>
>> So do I have to use gensym(), or not?
>
> As long as you are aware of the package in which the symbol ends up, I
> can't see how it'd matter. And nobody uses string indirect
> filehandles ($x = 'FH'; print $x 'hello') these days, we'd hope.
I ran into a gensym()-related snag while trying to be cute by doing:
my $fh = do { local *FH };
in a mod_perl content handler. It worked fine 90% of the time,
but it eventually broke, causing $fh to be undefined. This would
usually happen after an hour or so of use. I didn't bother chasing
it down, though. I just switched to gensym(). This was with perl
5.005_03 and mod_perl 1.2x, BTW. In 5.6.x you can just do this, IIRC:
my $fh;
open($fh, ...)
which does The Right Thing as far as name clashes goes, does it not?
-John
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Matt Sergeant wrote: > On Tue, 25 Apr 2000, Jeffrey W. Baker wrote: > > > I wish for a consistent API and documentation in the upcoming mod_perl 2.0 > > implementation. For example, right now, we have several different ways to > > tweak outgoing response headers. Some headers have their own method > > ($r->content_type), while others are aggregated ($r->header_out). Some of > > the ones that have their own accessor have slightly tweaked method names > > ($r->set_content_length). Worse, the documentation conflicts with the > > implementation. perldoc Apache says "You should not define any > > 'Content-XXX' headers by calling [header_out], because these headers use > > their own specific methods." However, there is no method content_length, > > you either have to set it using header_out, or use Apache::File and get > > set_content_length. > > > > The origin of these inconsistencies has, I think, been the years-long > > development of both mod_perl and Apache 1.x. Some headers may have their > > own accessors because they need to tweak something in the Apache core when > > they get set. Regardless, I propose a more consistent API for mod_perl > > 2.0. When setting an outbound header, I would prefer to use all method > > calls. I would also be fine with using a generic method like > > $r->header_out. However, I think that accessor method interface is > > preferrable because it lets us plug in funky logic that may be needed when > > a header is set. The header_out interface can have that too, but only if > > it switches on the hash key, in which case it is just identical to but > > slower than the accessor method interface. > > > > That's my two cents. Since I'm bitching about it, I volunteer to help be > > the interface and documentation police for 2.0 > > I'm with you, as long as you can do: > > PerlModule Apache::BackwardsCompatible I agree.
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Jeffrey W. Baker wrote: > I wish for a consistent API and documentation in the upcoming mod_perl 2.0 > implementation. For example, right now, we have several different ways to > tweak outgoing response headers. Some headers have their own method > ($r->content_type), while others are aggregated ($r->header_out). Some of > the ones that have their own accessor have slightly tweaked method names > ($r->set_content_length). Worse, the documentation conflicts with the > implementation. perldoc Apache says "You should not define any > 'Content-XXX' headers by calling [header_out], because these headers use > their own specific methods." However, there is no method content_length, > you either have to set it using header_out, or use Apache::File and get > set_content_length. > > The origin of these inconsistencies has, I think, been the years-long > development of both mod_perl and Apache 1.x. Some headers may have their > own accessors because they need to tweak something in the Apache core when > they get set. Regardless, I propose a more consistent API for mod_perl > 2.0. When setting an outbound header, I would prefer to use all method > calls. I would also be fine with using a generic method like > $r->header_out. However, I think that accessor method interface is > preferrable because it lets us plug in funky logic that may be needed when > a header is set. The header_out interface can have that too, but only if > it switches on the hash key, in which case it is just identical to but > slower than the accessor method interface. > > That's my two cents. Since I'm bitching about it, I volunteer to help be > the interface and documentation police for 2.0 I'm with you, as long as you can do: PerlModule Apache::BackwardsCompatible -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
newbie help installation problems modperl/apache
I am trying to use mod_perl with apache (1.22 & 1.3.12, respectively). I am having a multitude of problems, and cannot get hello world even working. I have loaded down & installed a bunch of cpan modules to support this (libwww-perl & prerequisites. this solved some things). as per the mod_perl INSTALL.apaci, I configure mod_perl for later apache building. (Everything=1, apaci=1, etc), because of issue 1. when configuring, I get a whole bunch of apxs warnings saying that it cannot find /usr/sbin/httpd. (this module is not here, this is not where it will be). it then warns me about mod_so, which I know I have compiled in, because of other parms that I use with apache. is this a problem? (i can make & make install). how do I tell mod_perl where the httpd module with be? issue 2. If I build apache, I can start it, run it, do all the other things I do with it. If I shut it down, and go back to mod_perl's make test, it blows chunks. It fails with a syntax error on line 80 of t/conf/httpd.conf. Invalid command 'Alias'. Does this tell me anything about what is wrong? The odd thing is that in my "normal" apache config, I have about 80 name virtual servers, and I specifically load mod_alias & similar modules. issue 3. apache is configured with --activate-module=src/modules/perl/libperl.a (as per the INSTALL.apaci). However, there is no such file. there are number of items in this directory, includign libperl.module the configuration, make, make install steps do not have any errors however. issue 4. It doesnt work. using the writing apache modules with perl & c book, I tried to use a "PerlSetEnv" command. (p.28) configtest says this is okay, but apache crashes upon starting. If i try to define a location (p.31), configtest gives me a syntax error on 'PerlHandler'. Ultimately, this tells me that something isnt right. jr john riehl ibucks, inc.
2.0 wishlist: consistent API and docs
I wish for a consistent API and documentation in the upcoming mod_perl 2.0 implementation. For example, right now, we have several different ways to tweak outgoing response headers. Some headers have their own method ($r->content_type), while others are aggregated ($r->header_out). Some of the ones that have their own accessor have slightly tweaked method names ($r->set_content_length). Worse, the documentation conflicts with the implementation. perldoc Apache says "You should not define any 'Content-XXX' headers by calling [header_out], because these headers use their own specific methods." However, there is no method content_length, you either have to set it using header_out, or use Apache::File and get set_content_length. The origin of these inconsistencies has, I think, been the years-long development of both mod_perl and Apache 1.x. Some headers may have their own accessors because they need to tweak something in the Apache core when they get set. Regardless, I propose a more consistent API for mod_perl 2.0. When setting an outbound header, I would prefer to use all method calls. I would also be fine with using a generic method like $r->header_out. However, I think that accessor method interface is preferrable because it lets us plug in funky logic that may be needed when a header is set. The header_out interface can have that too, but only if it switches on the hash key, in which case it is just identical to but slower than the accessor method interface. That's my two cents. Since I'm bitching about it, I volunteer to help be the interface and documentation police for 2.0 -jwb
write a filefrom a navigator
Hello, I'm a little perl developper, in a little french enterprise, (hexaflux). I make my period of training and I use an apache server 1.3x. I've got some problem with my server. It does not allow me to execute system commands in perl : "system (chmod 755 file.pl)" and "open (MYFILE, file.pl ". I f I execute my script by executing the following command : /usr/bin/perl /home/httpd/cgi-bin/script.pl, the file, "file.pl" is created and file.pl has the good permissions and it works! But if it is executed from the navigator it doesn't works!! I think that the permisions on the server are not good. But I don't know where to change the configuration of my server, access.conf, httpd.conf, srm.conf ? Can you help me, thank you. benoit PS: sorry for my poor english speaking!
Re: PerlHandler stopped working???
> "Matt" == Matt Sergeant <[EMAIL PROTECTED]> writes: Matt> I guess one important question is - why do we have to call SetHandler for Matt> PerlHandlers and not for any of the other handler phases. For all the Matt> other phases Apache/mod_perl automatically figures out if there's a Matt> handler installed and either runs perl code, or lets apache do its Matt> work. Why can't PerlHandler do the same? (as you can tell - I haven't dug Matt> into the internals of this - but I am curious). I've been pondering this for quite some time, and was considering a "magic mime type" that I'd deal with in the fixup handler... if the MIME type assigned by mod_mime or anything else in the mime phase is "text/html;PerlHandler=Apache::Registry", then the generic fixup handler would patch that to "text/html" and push a PerlHandler of Apache::Registry. That way you could do this: SetType text/html;PerlHandler=HTML::Mason SetType text/plain;PerlHandler=Apache::Registry SetType text/html Syntax is probably off... but I think you can see where I'm going with this. Bring the MIME type to mean both the "real" mime type as well as a PerlHandler if needed. I'm sure it's a 15 line FixupHandler... just haven't had time to tear down part of my site to test. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Deep recursion on subroutine "Apache::Constants::AUTOLOAD"
At 12:59 4/25/00 -0600, Martin Lichtin wrote:
>Doug MacEachern wrote:
>> > Anyone understand why
>> > perl -we 'use Apache::Constants; Apache::Constants::OK();'
>> > causes this problem?
>> what version of mod_perl are you using? '
>mod_perl 1.21, perl 5.00503
This reminds me of a problem that we had under mod_perl: I'm not sure it
exists in later versions, and if this has anything to do with your problem.
Just in case it might help you, here is how this would go:
package MyPackage::SubModule;
sub new { my $self = {}; bless $self; $self }
package MyPackage;
sub new { my $self = {}; bless $self; $self }
sub SubModule { MyPackage::SubModule->new( @_ ) }
^ ^
For some reason with _some_ combinations of Perl and mod_perl, the
following code would recurse infinitely and cause the "Deep recursion"
error message:
$mypackage = new MyPackage;
$submodule = $mypackage->SubModule( @parameters );
However, if you would write SubModule like this:
sub SubModule { 'MyPackage::SubModule'->new( @_ ) }
^^
there was no problem. This would indicate to me that there is some kind of
compile-time optimization in the version of Perl/mod_perl that incorrectly
assumes that "MyPackage::SubModule" is a subroutine reference, where in
fact it is a class reference. By putting the class reference between
single quotes, the optimization is apparently by-passed and the problem
disappeared.
Hope this helps.
Elizabeth Mattijsen
Integra Netherlands
Re: PerlHandler stopped working???
On Tue, 25 Apr 2000, Doug MacEachern wrote:
> > I guess the problem is that mod_mime implements SetHandler - and I'm not
> > convinced it should. If you were given the opportunity to do it all again
>
> understood, but this is how apache is designed, mod_perl is just going
> with the flow here.
>
> > I'd suggest it be done as follows:
> >
> > If a PerlTypeHandler returns OK, check if
> > @{$r->get_handlers('PerlHandler')} is true (i.e. there's a PerlHandler
> > waiting in the wings). If so, call $r->handler('perl-script').
>
> so why not just do that in your PerlTypeHandler?
I do now - just uploaded a new version. It's still not correct though - a
proper fix would have to pull SetHandler out of mod_mime altogether, I
guess. For example, say your config contains:
# PerlTypeHandler blah
SetHandler perl-script
PerlFixupHandler foo
And in foo::handler() you call $r->push_handler('perl-script'). Suddenly
it stops working when you uncomment the PerlTypeHandler there.
I guess one important question is - why do we have to call SetHandler for
PerlHandlers and not for any of the other handler phases. For all the
other phases Apache/mod_perl automatically figures out if there's a
handler installed and either runs perl code, or lets apache do its
work. Why can't PerlHandler do the same? (as you can tell - I haven't dug
into the internals of this - but I am curious).
> i don't think it's right
> for mod_perl to have that logic hardwired in. the other solution, is to
> let mod_mime do it's thang in the type phase, and do your thang in the
> fixup phase to override anything mod_mime did that you don't want.
Right. So what's the point of PerlTypeHandler again?... ;-) Seriously
though - Apache::MimeXML is the only PerlTypeHandler, as far as a quick
search reveals, apart from your examples in the book. So maybe it would be
worth investigating this further.
A fixup handler is an interesting solution... but can I stack
FixupHandlers? (I run most of my mod_perl code from a FixupHandler).
Also, you didn't pick up on something I sent to the list in another
thread... I have code that goes:
if ($r->current_callback eq 'PerlFixupHandler') {
$r->push_handlers('PerlHandler', \&code);
}
else {
&code($r);
}
so that I can install the module as either a fixup or a PerlHandler. The
fixup installed version is 4 times slower than calling the function
directly - is that to be expected? (we're talking 20 requests/sec vs 80
here - a huge difference).
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Apache XML Delivery Toolkit
I thought I'd just post here what I sent to the axdtk list, in case there
are people here who don't know what the heck I'm talking about... If this
perks your interest, send a mail to [EMAIL PROTECTED], download
the toolkit, and start asking questions...
What is the AXDTK?
It's a system very much like Cocoon (http://xml.apache.org/cocoon/), but
based on mod_perl. The idea is to allow a few things:
- Stylesheets and XML files get associated automatically using the w3c
semantics (http://www.w3.org/TR/xml-stylesheet).
- Pre and Post processing can be performed using mod_perl stacked
handlers.
- Output is cached automatically if the underlying system uses DOM,
otherwise the stylesheet processor developer has to implement caching
himself, however the hooks are provided for this.
- Stylesheets can cascade if based on DOM trees.
For those unfamiliar with Cocoon, here's what happens:
1. A request comes in for an XML file.
2. If someone has installed a stacked handler prior to
Apache::XMLStylesheet, that handler is called. One idea for such handlers
is to extract a media type by browser sniffing (e.g. sets the media to
"handheld"). Another idea is to take a preferred style from the
querystring such as "style=no%20images".
3. Apache::XMLStylesheet checks its cache for a matching set of combined
parameters (file, style, media). If the cache says that the XML file is
older than the cache, use the list of stylesheets in the cache. If the
cache is older than the file, parse the file for the xml-stylesheet
processing instructions.
4. Check all the stylesheets exist.
5. If all the stylesheets exist, check the difference in timestamps
between the xml file and all the stylesheet files, and the output cache
file. If any are newer than the output cache file, then we re-run all the
styles against the xml file. If they're all older we stop there, set the
filename to the cached file, and return DECLINED. Apache obliges and
returns the cached file to the browser for us.
6. If we re-create, we have mark off stylesheet type mappings against
modules or functions. That is, the type="..." attribute in the stylesheet
processing instruction gives us a pointer as to what module to use to
process that stylesheet (based on some info in your httpd.conf file). We
load that module and execute the function, passing in the stylesheet and
the xml filename as parameters.
7. Modules based on the DOM can use the mod_perl API to set the
$r->pnotes('dom_tree') value when they're done, rather than printing out
the results. This is how the caching works, and how cascading
works. Modules that aren't based on the DOM can't cascade... yet.
8. The resulting DOM tree is printed out both to the cache file and to the
browser. The DOM tree is disposed of.
That, in a nutshell, is it. Currently it's a work in progress. Today I
hope to finish the version that does all the caching work and cascading
stylesheets.
If anyone wants to volunteer to help, here's what I consider needs done:
- A cool web page ;-)
- Get Xalan/Xerces working on Unix. This is pretty vital to the success,
IMHO. See http://xml.apache.org/
- Write modules that plugin to this architecture that perform the
following functionality:
- SQL plugin using DBI. Should take an XML file (or DOM tree), parse
out connection information and run the SQL. Produce another DOM tree and
put that DOM tree in $r->pnotes('dom_tree')
- Implement other stylesheet processors, like XPathScript and NotXSLT
- Get the word out! Perl must not be behind in the XML world for much
longer!
Download AXDTK at http://xml.sergeant.org/download/
It's not well organised right now. The key component is
Apache::XMLStylesheet. To use that you need XML::Parser and
Apache::MimeXML(0.05). The only plugins available are Apache::XPathScript
and Apache::XPath::NotXSLT, and an XSLT plugin that's in the list
archive.
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12
> perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1 probably a long shot, but any difference if you build with USE_DSO=1 instead of USE_APXS ?
Re: PerlHandler stopped working???
> I guess the problem is that mod_mime implements SetHandler - and I'm not
> convinced it should. If you were given the opportunity to do it all again
understood, but this is how apache is designed, mod_perl is just going
with the flow here.
> I'd suggest it be done as follows:
>
> If a PerlTypeHandler returns OK, check if
> @{$r->get_handlers('PerlHandler')} is true (i.e. there's a PerlHandler
> waiting in the wings). If so, call $r->handler('perl-script').
so why not just do that in your PerlTypeHandler? i don't think it's right
for mod_perl to have that logic hardwired in. the other solution, is to
let mod_mime do it's thang in the type phase, and do your thang in the
fixup phase to override anything mod_mime did that you don't want.
RE: [RFC] XML/Apache Templating with mod_perl
> > Yeah that will be really cool... can you inform me about the progress on > this, if you made something ... I thought about something similar > not exact but > some sort of processor to handle XML(XSLT) -> HTML conversations + > some sort of caching tehnique, but I also like this > approachsomething like > this will help easy integrate XML stuff in the current scheme of producing > final HTML > Embperl 2.0 will be able to do such things, but it's a long way to go and will take some time until I have implemented this... 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: vanilla install failure 1.3.12/1.22/5.6.0
On Tue, 25 Apr 2000, Doug MacEachern wrote: > On Sun, 23 Apr 2000 [EMAIL PROTECTED] wrote: > > > Program received signal SIGSEGV, Segmentation fault. > > 0x806412e in perl_handler (r=0x8727d9c) at mod_perl.c:844 > > 844 dPPREQ; > > seems the common element in both of these reports is ssl. i'll build a > mod_perl+mod_ssl mix, so long as i can reproduce the problem, i'll have a > patch soon.. 'make test' passes 100% for me with: Apache/1.3.12 mod_perl/1.23_01-dev Perl/v5.6.0 mod_ssl/2.6.3 OpenSSL/0.9.5 suse 6.1 r->per_dir_config should never be NULL, i'm stumped without being able to reproduce this.
Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12
Doug MacEachern <[EMAIL PROTECTED]> writes: > On 22 Apr 2000, Michael Poole wrote: > > > I get a segfault on the first page access to Apache (it's just a > > request for / on the server). Backtrace: > ... > > That line of mod_perl.c is "dPPDIR;" > > However, r->per_dir_config is NULL, so the get_module_config() call there > > ends up dereferencing a NULL pointer to generate the SEGV. > > that's stange. what options did you give mod_perl's Makefile.PL? > did mod_perl's 'make test' pass? > what request is the server handling when this happens? perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1 'make test' refused to run since it was using APXS The server was handling "GET / HTTP/1.0" at the time (the first request made to the server). My "solution" to this point (suggested by Dave Mee) is to just use APACI to link mod_perl statically into Apache. It's worked perfectly so far, although it is a bit kludgy. Michael
RE: Unknown Error Message
On Mon, 24 Apr 2000, Ian Mahuron wrote: > > I get something similar when I wrap my call to Apache::Session::DBI in an > eval to try to catch it die()ing (ie. session id not found). IIRC, this is > a known bug in perl. right, which is fixed in 5.6.0 > > >> panic: POPSTACK > >> Callback called exit. > >
Re: gensym()
On Mon, 24 Apr 2000, Matt Sergeant wrote: > Is it necessary to use gensym() in a PerlHandler() - it doesn't seem > necessary to me. The book says "Ordinary bareword filehandles are prone to > namespace clashes". Is that the case for a perl module? I don't think > so. no, you don't have to use gensym(). we tried to promote the use of lexicals rather than globals in the book, but the choice is yours. with 5.6.0, 'open my $fh, ...' is the best solution.
Re: PerlHandler stopped working???
On Tue, 25 Apr 2000, Doug MacEachern wrote:
> On Sat, 22 Apr 2000, Matt Sergeant wrote:
>
> > On Sat, 22 Apr 2000, Matt Sergeant wrote:
> >
> > > The only thing I can think of, is that Apache::MimeXML is somehow stopping
> > > the PerlHandler phase from being executed. Can it do that (but still allow
> > > the PerlFixupHandler phase to execute)???
> >
> > OK, it was Apache::MimeXML... Which is very odd indeed. A bug in mod_perl
> > by the looks of things. All I'm returning from Apache::MimeXML, btw, is
> > OK or DECLINED. It was returning OK when PerlHandler stopped working. For
> > now I'll disable it, and set Mime types manually for .xml files - but
> > something is seriously not right there.
>
> as i already explained to matt in another email, if a TypeHandler returns
> OK, then mod_mime's type handler is not called. which means that
> SetHandler, AddType, etc., for that require will be ignored, unless you
> return DECLINED or implement them yourself (see Apache::MIME in ch8 of
> the eagle book)
OK, I'm looking at that now, and I realise you're just passing it straight
through to apache to do the right thing, but I think it's the wrong
thing... Hear me out.
Apache::MimeXML, like most non-PerlHandler handlers, is not designed as a
replacement for mod_mime, but to build on it. If I detect something as
XML, I'd like to say "OK, I'm done with this phase, let the next
continue". Likewise if I don't want to handle this phase (i.e. I want
mod_mime to do its thang) I return DECLINED. I don't want a MIME handler
that's supposed to add to mod_mime to change the fact that I have a
PerlHandler setup. In order to build Apache::MimeXML properly, I'd have to
build an entire replacement for mod_mime, in XS, parsing the configuration
for SetHandler, and I don't want to do that.
I guess the problem is that mod_mime implements SetHandler - and I'm not
convinced it should. If you were given the opportunity to do it all again
I'd suggest it be done as follows:
If a PerlTypeHandler returns OK, check if
@{$r->get_handlers('PerlHandler')} is true (i.e. there's a PerlHandler
waiting in the wings). If so, call $r->handler('perl-script').
If a PerlTypeHandler returns DECLINED, do it as you do now.
That should be backwards compatible with most code, I think. And not
interfere with things already setup in peoples httpd.conf/htaccess
files. Alternatively have the OK case remain the same, and have a new
return value (DONE?) that signfies to do the SetHandler part of mod_mime.
Convince me I'm thinking wrong, then I can get back to some real work ;-)
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: vanilla install failure 1.3.12/1.22/5.6.0
On Sun, 23 Apr 2000 [EMAIL PROTECTED] wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x806412e in perl_handler (r=0x8727d9c) at mod_perl.c:844 > 844 dPPREQ; seems the common element in both of these reports is ssl. i'll build a mod_perl+mod_ssl mix, so long as i can reproduce the problem, i'll have a patch soon..
Re: Deep recursion on subroutine "Apache::Constants::AUTOLOAD"
Doug MacEachern wrote: > > Anyone understand why > > perl -we 'use Apache::Constants; Apache::Constants::OK();' > > causes this problem? > > what version of mod_perl are you using? ' mod_perl 1.21, perl 5.00503
Re: End failed -- Cleanup aborted and other errors
On Sat, 22 Apr 2000, Gagan Prakash wrote: > Hi, > > We are in the process of moving our site www.adalbadal.com from the web > hosting company in India to iserver -- they do have mod_perl!!! > > Well during this process, some of our scripts are giving us: > END failed--cleanup aborted at /dev/null line 6. > Callback called exit at /dev/null line 6. > and an occassional > Out of memory! > > This server has Apache 1.3.11 > Mod_perl 1.21 might want to try 1.23. do this script have END blocks? if so, what are they doing?
Re: httpd could not be started
On Sat, 22 Apr 2000 [EMAIL PROTECTED] wrote: > It's a much simpler problem than I let on to before... > (thanks matt@telepath) whoops, disregard my last message then. > The error log shows what went wrong, but I am at a bit of > a loss on how to correct it. > > [info] mod_unique_id: using ip addr my.valid.ip.address > getpeername: Socket operation on non-socket > getsockname: Socket operation on non-socket > Error getting local address > > hostname returns the correct answer. > I put "my.ip.x.x localhost" into /etc/hosts > inetd is running, but all /etc/inetd.conf programs are > commented out. > I'm getting my IP from DHCP, but it is constant until midnight. you should use the loopback address for localhost: 127.0.0.1 localhost
Re: httpd could not be started
On Sat, 22 Apr 2000 [EMAIL PROTECTED] wrote: > I am trying to build httpd using DSO and mod_perl, mod_ssl > and mod_php (but that one hasn't come up yet) > > I'm on an unpatched RedHat 6.1 with a newly built 5.6.0 perl > (egcs 2.91.66) with mod_perl from CVS and mod_ssl-2.6.3-1.3.12 > for apache_1.3.12 what version of mod_perl are you using? did 'make test' pass? the server might be core dumping, if you could follow the hints in the SUPPORT doc for getting a stacktrace, we should be able to figure out why.
Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12
On 22 Apr 2000, Michael Poole wrote: > I get a segfault on the first page access to Apache (it's just a > request for / on the server). Backtrace: ... > That line of mod_perl.c is "dPPDIR;" > However, r->per_dir_config is NULL, so the get_module_config() call there > ends up dereferencing a NULL pointer to generate the SEGV. that's stange. what options did you give mod_perl's Makefile.PL? did mod_perl's 'make test' pass? what request is the server handling when this happens?
Re: PerlHandler stopped working???
On Sat, 22 Apr 2000, Matt Sergeant wrote: > On Sat, 22 Apr 2000, Matt Sergeant wrote: > > > The only thing I can think of, is that Apache::MimeXML is somehow stopping > > the PerlHandler phase from being executed. Can it do that (but still allow > > the PerlFixupHandler phase to execute)??? > > OK, it was Apache::MimeXML... Which is very odd indeed. A bug in mod_perl > by the looks of things. All I'm returning from Apache::MimeXML, btw, is > OK or DECLINED. It was returning OK when PerlHandler stopped working. For > now I'll disable it, and set Mime types manually for .xml files - but > something is seriously not right there. as i already explained to matt in another email, if a TypeHandler returns OK, then mod_mime's type handler is not called. which means that SetHandler, AddType, etc., for that require will be ignored, unless you return DECLINED or implement them yourself (see Apache::MIME in ch8 of the eagle book)
Re: ANNOUNCE: Apache-TicketAccess 0.10
On Sat, 22 Apr 2000, Michael Schout wrote: > Does this entry in the apache-modlist exist anywhere? I looked for it on CPAN, > but I cant even find MPB's directory on CPAN. If the module is no longer in > existance, then maybe my module can replace it? www.modperl.com (which is down at the moment) and it still exists in the book of course :) the examples tarball should probably be on cpan too. > I dont know what else I would name it. It is extremely similar to the > TicketAccess system in the eagle book, with a lot of extra features added in. please come up with a different name, it's way too confusing for two different modules to have the same name.
$r->get_handlers bug/oversight?
Hi all...
I've noticed that get_handlers() will return the enabled handlers
for a PerlPostReadRequestHandler, but not when it is specified as a
PerlInitHandler (either by calling
$r->get_handlers('PerlPostReadRequestHandler') or
$r->get_handlers('PerlInitHandler'). It is the same with
PerlHeaderParserHandler. An oversight?
Also, I can't get anything for PerlCleanupHandlers, which kinda
makes sense, since Cleanup isn't really a phase, per se (at least according
to the book). Does it make sense to add this to get_handlers() as well?
hope everone is well...
--Geoff
Re: Deep recursion on subroutine "Apache::Constants::AUTOLOAD"
On Fri, 21 Apr 2000, Martin Lichtin wrote: > Anyone understand why > > perl -we 'use Apache::Constants; Apache::Constants::OK();' > > causes this problem? what version of mod_perl are you using? from the command line you should get this error: % perl -we 'use Apache::Constants; Apache::Constants::OK();' Undefined subroutine &Apache::Constants::OK called at -e line 1. you can't use Apache::Constants outside of httpd.
Re: Apache::DBI disconnect?
On Mon, 24 Apr 2000, John S. Evans wrote: > Weird. The whole point of Apache::DBI (or so I understand it) is so that > your $dbh stays valid across CGI or Handler calls. Sure. But it does it magically. You're still supposed to call disconnect. That way, your code will also work without Apache::DBI. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: mod_proxy problem
> | > |DocumentRoot "/app/env_control/httpd/DocumentRoot" > | > | # disable mason for this location > | SetHandler default-handler > | > |ProxyPass/Test/ http://myhost:8084/Test/ > |ProxyPassReverse /Test/ http://myhost:8084/Test/ > | > > | > | When I try to access location /Test/, I get the following > | error: > | > | [Tue Apr 25 08:59:34 2000] [error] [client ] File > | does not exist: > | proxy:http://myhost:8084/Test/CheckDeployment/GetUKLs > | > | Can anybody give me some insight as to what I am doing wrong? > | I am new to mod_proxy and I don't even know where to start > | looking. > > Show us your (the destination in this > proxy config), a "ls -l" of > /app/env_control/httpd/DocumentRoot/Test/CheckDeployment and a "host > myhost". > > Ime I am running on HP-UX 10.20, there does not seem to be 'host' command. myhost:8084 is my development server (runs on the same box), here is a copy of the httpd.conf (myhost:8082 is SSL enabled, 8084 is not, I don't know if that makes a difference). Also attached the requested ls -l. ServerType standalone ServerRoot "/opt/perl5/apache" PidFile /var/iefadmn/apache/8084/logs/httpd.pid ScoreBoardFile /var/iefadmn/apache/8084/logs/httpd.scoreboard Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 3 MaxSpareServers 5 StartServers 3 MaxClients 8 MaxRequestsPerChild 10 ClearModuleList AddModule mod_env.c AddModule mod_log_config.c AddModule mod_mime.c AddModule mod_alias.c AddModule mod_access.c AddModule mod_auth.c AddModule mod_so.c AddModule mod_setenvif.c AddModule mod_perl.c Port 8084 User intranet Group users ServerName myhost AllowOverride None PerlInitHandler Apache::StatINC Order allow,deny Deny from all PerlSetVar ServerAlias myhost PerlAccessHandler Intranet::Alias UseCanonicalName On HostnameLookups Off ServerSignature On TypesConfig /opt/perl5/apache/conf/8084/mime.types LogFormat "%h %l %u %t \"%r\" %>s %b" common ErrorLog /var/iefadmn/apache/8084/logs/error_log LogLevel warn CustomLog /var/iefadmn/apache/8084/logs/access_log common SetEnv RC_FILE /app/env_control/repdata/iefit.rc PassEnv ORACLE_HOME PerlPassEnv ORACLE_HOME PerlRequire /opt/perl5/apache/conf/8084/startup.pl DocumentRoot "/app/env_control/httpd/DocumentRoot" Options FollowSymLinks AllowOverride None Order allow,deny Allow from all AuthType Basic AuthName "Environment Support and Projects (testing)" PerlAuthenHandler RCM::Authenticate PerlAuthzHandler RCM::Authorise AuthAuthoritative on require role TEST01 TSTAU1 Alias /icons/ "/var/iefadmn/apache/icons/" Alias /images/ "/var/iefadmn/apache/images/" Order allow,deny Allow from all Order allow,deny Allow from all PerlRequire /opt/perl5/apache/conf/8084/handler.pl DefaultType text/html SetHandler perl-script PerlHandler HTML::Mason SetHandler perl-script PerlHandler Intranet::mod_ssl_error Alias /Images /app/env_control/httpd/Components/Images Order allow,deny Allow from all SetHandler perl-script PerlHandler HTML::Mason AddEncoding x-compress Z AddEncoding x-gzip gz BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 Alias /Errors /app/env_control/httpd/Errors Order allow,deny Allow from all SetHandler perl-script PerlHandler HTML::Mason ErrorDocument 403 /Errors/NotAuthorised ErrorDocument 404 /Errors/NotFound --- ls -l /app/env_control/httpd/DocumentRoot/Test/CheckDeployment total 8 -rw-r--r-- 1 iefit dba 3176 Apr 12 13:28 GetUKLs
Re: -DPERL_NO_GET_CONTEXT horks everything
On Tue, 25 Apr 2000, Doug MacEachern wrote: > "cvs up early, cvs up often" word
Re: -DPERL_NO_GET_CONTEXT horks everything
i hate to see you suffer this pain, when the proper fix was posted to p5p on friday (see patches/no_get_context.pat) and modperl-2.0/00README_FIRST no longer suggests building Perl with -DPERL_NO_GET_CONTEXT "cvs up early, cvs up often"
Re: [RFC] XML/Apache Templating with mod_perl
On Tue, 25 Apr 2000, Leslie Mikesell wrote: > According to Matt Sergeant: > > > In case you missed it - I just announce the Apache XML Delivery Toolkit to > > both the modperl list and the Perl-XML list. With it you can develop an > > XSLT Apache module in 13 lines of code (no caching, but it works). > > I saw it, but perhaps misinterpreted the 'not' in the xslt package. > Is this intended to be fairly compatible with IIS's 'TransformNode' > handling of xml/xsl (i.e. can I use the same xsl files)? No. It's definitely Not XSLT compatible. Sorry if it wasn't clear. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [RFC] XML/Apache Templating with mod_perl
According to Matt Sergeant: > In case you missed it - I just announce the Apache XML Delivery Toolkit to > both the modperl list and the Perl-XML list. With it you can develop an > XSLT Apache module in 13 lines of code (no caching, but it works). I saw it, but perhaps misinterpreted the 'not' in the xslt package. Is this intended to be fairly compatible with IIS's 'TransformNode' handling of xml/xsl (i.e. can I use the same xsl files)? Les Mikesell [EMAIL PROTECTED]
-DPERL_NO_GET_CONTEXT horks everything
Building Perl 5.6 with -DPERL_NO_GET_CONTEXT breaks just about every program that uses the Perl C API. DBI, Storable mod_include, and mod_perl 1.23 are all unable to compile with this build flag. Bummer. I skimmed perldelta and perlguts to see what was what. It was pretty easy to fix Storable by adding dTHX wherever the compiler complained about my_perl being undefined. But the way I read perlguts, couldn't we build perl without -DPERL_NO_GET_CONTEXT and just #define it in the mod_perl 2.0 sources? That way, we could have an efficient mod_perl, but not have to hack on every module in CPAN. I think. -jwb
Re: [OT] Lotus Domino as Web server ?
Jean-Denis Girard wrote: > > Hi dear modperlers, > > We have a client here willing to use Domino to serve > his Web site. > I started considering Domino a while ago. My conclusion was to flee from it. I haven't used it and these were the opinions of real programmers that used it. I'll try to recall things they told me ; - It uses a lot of CPU and RAM, if you think mod_perl eats RAM, you've never used domino. I've seen this happening in intranet with around 1000 users. They had to install alphas with NT. - It does not farming. If you install domino you'll end up having a lot of domains, one for every section of your web, each one in a server. Your users will go crazy searching dead links and asking you what server holds now the pages they were using. Because you'll start moving databases to a new server as soon as the older started die of resources. - Amazing lack of features, the API to the web server maybe exists but no developer I talked to knew nothing about sending headers, internal redirects and so. I was comparing to mod_perl, and HTML::Mason, the dhandler and autohander stuff was very important for me and I wanted something like this. I didn't find it. - It does not SQL, building an application for the web with domino takes a big effort of analising, programming and maintaining. A thing that would be very easy with a SQL database can be very hard or impossible to do with domino. I was told is hard to feed such a database from 3rd party data. And if you must add more data again to domino is harder again. - It's impossible to separate content from formatting. - You don't embed a language in HTML, you ask domino about inserting html inside your code. My conclusion was it's no good for web programming. I went to a super human software lotus show and it was very disapointing, a lot of vapourware. I thought it must be very bad when they admitted nested tables didn't work at all in domino 4.x, and started working at 5.0. In addition I must say mod_perl has a lot of features never dreamed by people that use Domino or IIS+ASP. I have asked to other programmers friends of mine who use these platforms, no one uses mod_perl and they think their tools are far better than mine and easier to use. I quit advocacing mod_perl. For every feature they lack, they have work arounds or don't use it. -- - frankie -
Deep Recursion with File::Copy
Hi.
We are running Server Version: Apache/1.3.9 (Unix) mod_perl/1.21 on a
Linux system.
Having problems with a "Deep Recursion" when using the copy method of
File::Copy.
Basically, this part of the copy code isn't working properly.
# if (defined &syscopy && \&syscopy != \©
# && !$to_a_handle
# && !($from_a_handle && $^O eq 'os2' ) # OS/2 cannot handle
handles
# && !($from_a_handle && $^O eq 'mpeix') # and neither can
MPE/iX.
# )
# {
# return syscopy($from, $to);
# }
The if should fail, as \&syscopy should equal \©, but under modPerl
it doesn't work.
Why are they different under apache/Modperl? Is this because of the
way that Apache::Registry wraps the scripts in subroutines?
Anyways, is there an appropriate patch for this? We are just commenting
this part out of the File::Copy module for now.
thanks for any help
AXDTK Mailing List open!
I had a pretty good response to the offer of a mailing list for the Apache XML Delivery Toolkit - and very fast too! So before more people say yes go ahead... send a blank mail to mailto:[EMAIL PROTECTED] and join the list! -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Mailing list for AXDTK
I'm thinking of starting a separate mailing list for the Apache XML Delivery Toolkit. For those who don't know, the Apache XML Delivery Toolkit now offers the core functionality of Cocoon (http://xml.apache.org/cocoon/) in mod_perl, without the proprietary extension that cocoon has implemented (because everything they've done can be achieved without any processing instructions). In the near future I hope to add the following: - XSLT parsing using Xalan (once it's ported to Linux and stable) - SQL Pre-processing - Embedded Perl (already available to some extent) If there's interest in this mail me direct and I'll set something up. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [RFC] XML/Apache Templating with mod_perl
On Tue, 25 Apr 2000, raptor wrote: > Yeah that will be really cool... can you inform me about the progress on > this, if you made something ... I thought about something similar not exact but > some sort of processor to handle XML(XSLT) -> HTML conversations + > some sort of caching tehnique, but I also like this approachsomething like > this will help easy integrate XML stuff in the current scheme of producing > final HTML In case you missed it - I just announce the Apache XML Delivery Toolkit to both the modperl list and the Perl-XML list. With it you can develop an XSLT Apache module in 13 lines of code (no caching, but it works). -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [RFC] XML/Apache Templating with mod_perl
Yeah that will be really cool... can you inform me about the progress on this, if you made something ... I thought about something similar not exact but some sort of processor to handle XML(XSLT) -> HTML conversations + some sort of caching tehnique, but I also like this approachsomething like this will help easy integrate XML stuff in the current scheme of producing final HTML see ya = iVAN [EMAIL PROTECTED] =
Re: mod_proxy problem
| |DocumentRoot "/app/env_control/httpd/DocumentRoot" | | # disable mason for this location | SetHandler default-handler | |ProxyPass/Test/ http://myhost:8084/Test/ |ProxyPassReverse /Test/ http://myhost:8084/Test/ | | | When I try to access location /Test/, I get the following | error: | | [Tue Apr 25 08:59:34 2000] [error] [client ] File | does not exist: | proxy:http://myhost:8084/Test/CheckDeployment/GetUKLs | | Can anybody give me some insight as to what I am doing wrong? | I am new to mod_proxy and I don't even know where to start | looking. Show us your (the destination in this proxy config), a "ls -l" of /app/env_control/httpd/DocumentRoot/Test/CheckDeployment and a "host myhost". Ime
mod_proxy problem
I have the following directives in my httpd.conf: ... DocumentRoot "/app/env_control/httpd/DocumentRoot" # disable mason for this location SetHandler default-handler ProxyPass/Test/ http://myhost:8084/Test/ ProxyPassReverse /Test/ http://myhost:8084/Test/ ... When I try to access location /Test/, I get the following error: [Tue Apr 25 08:59:34 2000] [error] [client ] File does not exist: proxy:http://myhost:8084/Test/CheckDeployment/GetUKLs Can anybody give me some insight as to what I am doing wrong? I am new to mod_proxy and I don't even know where to start looking. Kees Vonk
RE: ANNOUNCE: Apache::AuthCookie 2.007
Hi Ken, the patch I send you for overwriting the login_form seems not to be in 2.007. Are there any reason for this or did you just forget it? 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Apache::DBI disconnect?
"John S. Evans" wrote: > > Weird. The whole point of Apache::DBI (or so I understand it) is so that > your $dbh stays valid across CGI or Handler calls. That's right. The disconnect call is a no-op when using Apache::DBI. > I can only think of two reasons why I get the error message: > > 1) My child process is dying, and the DBI code is telling me that I never > called disconnect() on that $dbh. I don't think this is the case, since the > line (#119) in Apache::DBI that is referenced in the error is in the > connect() call. > > 2) My $dbh has timed out, and Apache::DBI is attempting to reconnect. The > code author decided not to perform a disconnect() because they knew the > connection was already timed out. Those are both good guesses. I'd say the latter as well. One of your db handles probably failed to ping and got removed. I wouldn't worry about it. - Perrin
