Re: problem with mod_perl 2.0 + apache 2.0 and proxyreq
John Chiu wrote: Thanks in advance. I've tried all the archives and google'd but I have not found anything that would help. I'm running RH 8.0, httpd-2.0.40-11.5 and mod_perl-1.99_05-3 from the RedHat distribution. I'm trying to create a small proxy module that will check a non-proxy request and depending on stuff dynamically transform it into a proxy request using mod_proxy. 1.99_05 is a way too old. Lots of bugs were fixed since that release. Upgrade to at least 1.99_09 or better the current cvs. 1.99_10 will be released as soon as perl-5.8.1 is released. I'm following the example in Chapter 7 (page 370) of the Writing Apache Modules with Perl and C. I know that the book is based on the older apache 1.3 server and associated mod_perl. However, I have not found anything in my readings to indicate that this would not work any more. my $r =3D shift; [... code snipped ...] BTW, you mailer has mangled the source code, s/=/=3D/ Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request. The apache error log indicates (with some debugging) that it is looping on the GET of goodbye.html. Additional debuging indicates that $r-proxyreq is always 0, so it's looping. My questions are: 1.Did sometime change in apache 2 or mod_perl 2 so that you cannot set proxyreq anymore: ie. $r-proxyreq(1). 2.How do you set proxyreq if $r-proxyreq(1) is not the correct method? 3.Is the logic wrong in this proxy example? How can we possible know what the problem is if you don't show the relevant configuration section? Most likely you have a broken configuration and should advise first the mod_proxy documentation. http://httpd.apache.org/docs-2.0/mod/mod_proxy.html To make sure that the problem is not in mod_perl, I've added a new modules/proxy test to the mp2 test suite, based on that example from the eagle book. Try it and if you succeed to break it, then we will fix it. You will need to retrieve the cvs version in order to get it. http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution (note: I have just committed the test, so if you use the snapshot, which is updated every 6 hours, it may not be there, so use the normal cvs checkout) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
mod_perl 2 APache 2.0 MPM
All, Starting to strike the first blows with Apache 2.0. I am now wondering about thread safety with mod_perl 2. Will mod_perl support a threaded MPM Apache config ? Thanks,
Re: mod_perl 2 APache 2.0 MPM
Sinclair, Alan (CORP, GEAccess) wrote: All, Starting to strike the first blows with Apache 2.0. I am now wondering about thread safety with mod_perl 2. Will mod_perl support a threaded MPM Apache config ? Why using the future tense, it does support the threaded mpm pretty much from the very beginning. re: thread-safety see: http://perl.apache.org/search/swish.cgi?query=thread-safesbm=SecIsubmit=search __ 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
Mod_perl and Apache 2.0
Has anyone tried compiling mod_perl under apache 2.0? Also, what is the word on mod_perl 2.0? -- Jeff Stuart [EMAIL PROTECTED]
Re: Mod_perl and Apache 2.0
Well, from the looks of the cvs commits, doug seems to be compiling mod_perl under apache 2.0 quite regularly :) With the complete rewrite there's been plenty of work to do. The word on it is here: http://perl.apache.org/~dougm/modperl_2.0.html its still in heavy development by doug - i would say the best thing to do is watch the commits if you want to keep up with it. sterling On Wed, 28 Feb 2001, Jeffrey A. Stuart wrote: Has anyone tried compiling mod_perl under apache 2.0? Also, what is the word on mod_perl 2.0? -- Jeff Stuart [EMAIL PROTECTED]
mod_perl and Apache 2.0 alpha on win32
Howdy. As mod_perl and Apache 1.3 won't thread on NT/2000, I'm asking if anyone has any experience with mod_perl and Apache 2.0 alpha. I've built apache which runs (though it doesn't like my old configuration file very much!), but can't get mod_perl running. Mod_perl builds OK (apparently) but I don't get an ApacheModulePerl.dll out at the end, I get a Leak.dll and a Symbol.dll. Has anyone else been here? Words of wisdom appreciated. Replies off-list if alpha software is considered off-topic, otherwise go ahead and share. Regards, Alistair
Re: mod_perl on Apache 2.0
On Wed, 3 Nov 1999, Jeffrey Baker wrote: There was a short discussion a while ago about getting mod_perl working with Apache 2.0. Since Apache 2.0 can actually be built and run on a few platforms now, I think it is worth taking a lot at this for real. I started to fiddle with 5.005_63 and perl_clone(), running concurrent interpreters in seperate threads. it didn't core dump, like old MULTIPLICTY Perls would, but didn't work quite right either. sarathy says it's not quite ready yet, but it looks very promising from what I've seen so far. I hope to start looking into 2.0 things once I catch up here, and get 1.22 released.
RE: mod_perl on Apache 2.0
I'm assuming that Perl itself is reentrant, since it has been embedded in multithreaded environments before (IIS). Hopefully someone can comment on that. Perl 5.005 has experimetal thread support, Perl 5.006 might be stable enought to really use it. What ActiveState has done for IIS, is to pack the Perlinterpreter in a single C++ object (compile Perl with PERL_OBJECT) and now every request can get his own private Perlinterpreter. This model (maybe a pool of Perlinterpreters) may also work for mod_perl. Jochen Wiedman already has done some work on make mod_perl compile with a Perl that is build with PERL_OBJECT, but a lot of work is left... Gerald --- Gerald Richter ecos electronic communication services gmbh Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl E-Mail: [EMAIL PROTECTED] Tel:+49-6133/925151 WWW:http://www.ecos.de Fax:+49-6133/925152 ---
Re: mod_perl on Apache 2.0
"C. Jon Larsen" wrote: One of the main reasons I use mod_perl is because of the pre-fork caching I can do in the parent that the children can share cheaply. I take huge data structures and assemble them in ram as read-only databases (read hash tables) that are much faster and simpler to access than sql (I use sql only where my data is read/write). With all this talk about threaded perl interpreters what I'd like to be sure of is that in Apache 2.0 my model does not break. Can each private perl interpreter keep its cached (shared) data structures in memory ? Most of my mod_perl processes are big - 10-12 MB, but easily 90+ percent of that is shared. I like this setup, and want to be sure that apache 2.0 does not break this in any way. threads ? are they really appropriate for everyone ? can the old behavior be maintained ? If not, then we would seem to be moving to a more php-like environment, which would be a major bust for me. I can triple (sometimes more) the performance of my handlers by packing my data that is read-only into memory, and using sql only as needed ! Any comments ? Am I off base ? Worrying without cause ? No, you certainly aren't off base. These are precisely the issues that need to be worked out. Apache 2.0 doesn't have a fixed process model. It has a modular multi-process model, or MPM. All of the MPMs so far have n processes and p threads per process. You could have a purely threading Apache (n=1, p=1..*), or a classic Apache (n=1..*, p=1), or something in between. Threads could be kernel threads, pthreads, userland threads, lightweight processes, or something else. Obviously when you are deploying Apache, you need to pick one of the MPMs. Doug indicated earlier that he wanted to make mod_perl work with all MPMs, so any work we do is going to need to be general. If your work relies on pre-fork caching of data, then you will be able to use Apache 2.0 with a pre-fork MPM. Of course, you could also stick with Apache 1.3.x indefinitely. It is, after all, a fine product. You mention that your data structures are read-only. I don't think you are going to have any problems with the thread model, because read-only data is inherently thread safe. The problems don't happen until you are trying to do mixed reading and writing with the same data structure by multiple threads. Hope that answers some questions, Jeffrey
RE: mod_perl on Apache 2.0
Perl threads have nothing to do with OS level threads. They aren't native; they're part of the language itself and don't depend or rely on POSIX threads, native threads, or other such things. In particular, Perl threading doesn't mean that Perl is thread safe. Yes, Perl threads are not OS threads. I am not an thread expert, but Perl threads depends on OS threads, so it maybe possible to "attach" a Perl thread to an OS thread (sometime in the future, when Perl threads are stable) What Doug has said we'll do, and what makes sense, is have a Perl interpreter in memory for each thread. With Perl compiled with -DMULTIPLICITY, we can have multiple interpreters in a single process. They will still benefit from code sharing and such in memory, but there will be per-thread overhead. Plus, AFAIK, no Perl distribution comes shipped with multiplicity, so we'll likely have to require Perl recompilation before mod_perl compilation. This is the way to go for now. We can use -DMULTIPLICITY or -DPERL_OBJECT, that doesn't matter, both will allocate a number of Perl interpreters and they could be assign to a particular thread. Gerald
Re: mod_perl on Apache 2.0
Matt Sergeant wrote:
On Thu, 04 Nov 1999, Jeffrey Baker wrote:
I'm assuming that Perl itself is reentrant, since it has been embedded
in multithreaded environments before (IIS). Hopefully someone can
comment on that.
This work was based on PERL_OBJECT support, which is currently only
available on windows. It's a perl interpreter wrapped up in a C++ object so
that the whole thing is reentrant. For 5.6 I believe a similar
functionality but in C is being added (or is moving out of experimental
mode) called MULTIPLICITY.
I believe -DMULTIPLICITY is already in 5.005_03. Check "man perlembed".
Now suppose we have more than one interpreter instance
running at the same time. This is feasible, but only if
you used the -DMULTIPLICITY flag when building Perl. By
default, that sets PL_perl_destruct_level to 1.
Let's give it a try:
#include EXTERN.h
#include perl.h
/* we're going to embed two interpreters */
/* we're going to embed two interpreters */
#define SAY_HELLO "-e", "print qq(Hi, I'm $^X\n)"
int main(int argc, char **argv, char **env)
{
PerlInterpreter
*one_perl = perl_alloc(),
*two_perl = perl_alloc();
char *one_args[] = { "one_perl", SAY_HELLO };
char *two_args[] = { "two_perl", SAY_HELLO };
perl_construct(one_perl);
perl_construct(two_perl);
perl_parse(one_perl, NULL, 3, one_args, (char **)NULL);
perl_parse(two_perl, NULL, 3, two_args, (char **)NULL);
perl_run(one_perl);
perl_run(two_perl);
perl_destruct(one_perl);
perl_destruct(two_perl);
perl_free(one_perl);
perl_free(two_perl);
}
--
Jeffrey W. Baker * [EMAIL PROTECTED]
Critical Path, Inc. * we handle the world's email * www.cp.net
415.808.8807
