upgrading to apache 2
I am currently running apache 1.3.26 with mod_perl 1.36 and Perl 5.6.1 on my web server which is a Sun Solaris machine running Solaris 7. We have just bought a new Sun machine for our web server and I will be installing Solaris 9. I figure that now is a good time to upgrade my software. I would like to install Apache 2, mod_perl 2, and Perl 5.8. Does anyone know of any specific problems, issues that I should look out for? I am also running MySQL and I use the perl DBI-DBD modules for interfacing between apache and mysql. If anyone has any suggestions or tips to pass along I would appreciate it. Malki Cymbalista Webmaster, Weizmann Institute of Science Rehovot, Israel 76100 Internet: [EMAIL PROTECTED] 08-934-3036
Re: upgrading to apache 2
Hello there, On Wed, 17 Sep 2003, Malka Cymbalista wrote: I am currently running apache 1.3.26 with mod_perl 1.36 and Perl 5.6.1 on my web server which is a Sun Solaris machine ... I would like to install Apache 2, mod_perl 2, and Perl 5.8. While Apache version 2 is stable, mod_perl version 2 is not yet. If you are prepared to accept some of the issues which arise during the early stages of software development then by all means try mod_perl version 2. If not, then stay with the latest version 1, which means you must also use a version 1 Apache. There have been several issues with Perl 5.8.0, and although I have had no problems with 5.8.0 on my own development boxes, in either case I would wait for Perl 5.8.1 before release into a user environment - and I would test that for a couple of months first. As far as I can tell Perl 5.6.1 is as good a release of Perl as any. 73, Ged.
Re: mod_perl.pm and Apache 2
Chris Majewski wrote: OK, I've resolved the mod_perl.pm dependency by reinstalling mod_perl-1.99_08 (from src). But now I get this when trying to install Apache::Cookie Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/perl5/5.6.1/lib/sun4-solaris-64int /usr/perl5/5.6.1/lib /usr/perl5/site_perl/5.6.1/sun4-solaris-64int /usr/perl5/site_perl/5.6.1 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.6.1/sun4-solaris-64int /usr/perl5/vendor_perl/5.6.1 /usr/perl5/vendor_perl .) at Makefile.PL line 54. BEGIN failed--compilation aborted at Makefile.PL line 54. Apache::Cookie has not (yet) been ported over to mod_perl 2.0. what you want is: Apache 1.3.27 (http://www.apache.org/dist/httpd/apache_1.3.27.tar.gz) mod_perl 1.27 (http://perl.apache.org/dist/mod_perl-1.27.tar.gz) good luck. --Geoff
Help - Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl
Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl ? My goal is to rewrite some parts of the body of a web page before it is sent back to the client (Output Filter). I have it working in Apache 2 using an Output Filter. However, I'm forced to return to Apache 1.3.x; I really need this functionality ! Thanks, David
Help - Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl - Continue
Sorry - implemented via mod_perl 1.x - Original Message - From: David Culp To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 11:13 PM Subject: Help - Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl ? My goal is to rewrite some parts of the body of a web page before it is sent back to the client (Output Filter). I have it working in Apache 2 using an Output Filter. However, I'm forced to return to Apache 1.3.x; I really need this functionality ! Thanks, David
Re: Help - Can Apache 2 Filters be implemented in Apache 1.3.x viamod_perl
On Thu, 2003-03-06 at 23:13, David Culp wrote: Can Apache 2 Filters be implemented in Apache 1.3.x via mod_perl [1.x]? No. However, there are a couple of method for doing this in 1.x. See Apache::Filter or Apache::OutputChain. - Perrin
Re: Apache 2?
GC == Grant Cooper [EMAIL PROTECTED] writes: GC Is there any documention of a HOWTO or a tutorial about a lightweight GC front-end proxy that loads the data from the mod_perl try this: perldoc mod_perl_tuning It comes with mod_perl, conveniently. Nobody has sent me any updates in two years, so I assume nobody has come up with anything better ;-) I still use the proxypass thing with front end running SSL and back end doing all the heavy lifting in Template Toolkit. I call that my application server to let the buzz-word compliant be happy. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Apache 2?
On Tue, 2002-11-26 at 05:15, Philip Mak wrote: Is the 'front end' and 'back end' apache servers on the 'same box'? My problme is that I had one web server. and I did the FE and BE bit (BE being on the loop back address). to free up some major resources since mod_perl apache gets huges. I didn't need 20meg process serving up 2K images :) and had about 20 to 30 smaller apache process doing the 'static' content serving. I'm currently running Apache2 in a development enviroment. Going to be upgradeing my web servers with 2.0. Most sites will work nicly. I have found that the memory resource problem doesn't excist with 2.0 when you compile with 'worker' or fully threaded. I'm running 2 processes of apache and each of htem have like 20 threaded. performce seems good with just running one apache server. didn't do any real load testing, but I'm sure 2.0 is going to blow 1.3.x away. -- Jason These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
On Sat, Nov 30, 2002 at 12:45:50PM -0500, Jason Czerak (Jasnik) wrote: Is the 'front end' and 'back end' apache servers on the 'same box'? My problme is that I had one web server. and I did the FE and BE bit (BE being on the loop back address). to free up some major resources since mod_perl apache gets huges. I didn't need 20meg process serving up 2K images :) and had about 20 to 30 smaller apache process doing the 'static' content serving. Yes, that's exactly what I do. I have found that the memory resource problem doesn't excist with 2.0 when you compile with 'worker' or fully threaded. I'm running 2 processes of apache and each of htem have like 20 threaded. performce seems good with just running one apache server. didn't do any real load testing, but I'm sure 2.0 is going to blow 1.3.x away. Well, there's multiple benefits of running a separate frontend and backend server: 1. As stated above, the static HTML/GIF/JPG/etc. files don't have to be served by the heavyweight mod_perl process. 2. If the backend is serving a large file, the frontend can retrieve the entire file from the backend and free it up immediately, so that a client with a slow modem will not tie up the backend for the time it takes to download. 3. If you have different sites (presumably owned by different people) on your server, all the backend servers can execute with different userids so that the backend server of one site doesn't have to be able to read the files of another site. And, everyone can change their own server configuration. We know that Apache 2 confers benefit #1 without needing a separate frontend and backend. Benefit #2 seems to be planned, but isn't here yet. ...What about benefit #3?
Re: Apache 2?
3. If you have different sites (presumably owned by different people) on your server, all the backend servers can execute with different userids so that the backend server of one site doesn't have to be able to read the files of another site. And, everyone can change their own server configuration. We know that Apache 2 confers benefit #1 without needing a separate frontend and backend. Benefit #2 seems to be planned, but isn't here yet. ...What about benefit #3? #3: --with-mpm=perchild which is a work in progress http://httpd.apache.org/docs-2.0/mod/perchild.html notice the new AssignUserID and ChildPerUserID directives which now can set different uid/gid for each group of processes/threads. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Issac Goldstand wrote: - Original Message - From: Stas Bekman [EMAIL PROTECTED] . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler start of buckets Filter API End of buckets Core Output client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? From a quick read through: server/core.c:static apr_status_t core_output_filter(ap_filter_t *f, apr_bucket_brigade *b) I don't think core_output_filter does anything to buffer up the data and release the handler. The only buffering it does is if it doesn't have *enough* bytes to send so it waits for the next brigade. In order to understand how the new model works you really have run the snooping filter and study the output. The important outcome that you gain is that filters are called in a pipeline, i.e. the response handler sends a portion of data to the first filter, which immediately passes that data to the next filter, and so on, while all previous filters that have already passed the first chunk await for the latter filters to return. That's my understanding so far, please correct me if I'm wrong. So if you want to release the handler asap, you need a filter that will buffer up the data and feed it to the remaining filters at the speed they request. It should probably be inserted just before the core_output_filter, so all the processings will be already completed by that time. Think of it as an extension to the core_output_filter which buffers things up. And the cool thing is that you can inject it only when you want it, e.g. you don't want it for non-mod_perl requests. And of course it's not mod_perl specific like you've mentioned, but I don't really know of any other producers that consume a lot of memory and therefore for which we want to minimize their number and keep them busy for real all the time. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
On Tue, 26 Nov 2002, Philip Mak wrote: On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote: What do yo mean a modem will tie up the Server? I've never heard this before. Let's say you have a mod_perl page that returns a 100k document, and a 28.8k modem downloads that document. The mod_perl process that is serving that document will be tied up until that modem finishes downloading the document, which is inefficient since the mod_perl processes take up a lot of memory. A lightweight front-end proxy that loads the data from the mod_perl process all at once and then feeds it to the modem would save memory. Things are bit complicated. Kernel can buffer some part of document and there is Apache feature named lingering close. For example, client's speed is 3K/s. If you have 64K kernel TCP send buffer then mod_perl will write 64K very soon but it will wait about 12 seconds to write other 36K. And after mod_perl will have written these 36K it will wait 2 second in lingering close. Even you increase kernel TCP send buffer (it's not always good idea) to 100K anyway you still 2 second lingering close delay for slow clients. Note that you never see lingering close state in /server-status (at least in Apache 1.3) - such processes are marked as idle but they are not really idle - they can not handle requests. Also lingering close time is not accounted in %T directive in the log. You can only estimate the count of Apache processes that is in linegring close state using netstat utulity and looking for FIN_WAIT2 socket states. Igor Sysoev http://sysoev.ru/en/
Re: Apache 2?
- Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Philip Mak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 27, 2002 2:24 AM Subject: Re: Apache 2? . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler start of buckets Filter API End of buckets Core Output client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? Issac
Apache 2?
These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
What do yo mean a modem will tie up the Server? I've never heard this before. - Original Message - From: Philip Mak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 2:15 AM Subject: Apache 2? These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote: What do yo mean a modem will tie up the Server? I've never heard this before. Let's say you have a mod_perl page that returns a 100k document, and a 28.8k modem downloads that document. The mod_perl process that is serving that document will be tied up until that modem finishes downloading the document, which is inefficient since the mod_perl processes take up a lot of memory. A lightweight front-end proxy that loads the data from the mod_perl process all at once and then feeds it to the modem would save memory.
Re: Apache 2?
On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote: Is there any documention of a HOWTO or a tutorial about a lightweight front-end proxy that loads the data from the mod_perl I wrote a guide a while back on how to install mod_accel and mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it will work with Apache 2.x. http://www.aaanime.net/pmak/apache/mod_accel/
Re: Apache 2?
Philip Mak wrote: On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote: Is there any documention of a HOWTO or a tutorial about a lightweight front-end proxy that loads the data from the mod_perl I wrote a guide a while back on how to install mod_accel and mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it will work with Apache 2.x. http://www.aaanime.net/pmak/apache/mod_accel/ and of course your perl.apache.org docs: http://perl.apache.org/docs/1.0/guide/strategy.html http://perl.apache.org/docs/1.0/guide/scenario.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Philip Mak wrote: These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now? Theoretically with mod_perl 2.0 with Apache2.0 threaded mpms architecture the need for the front-end/back-end solution has gone away, because now you can have a few threads running Perl interpreters and many other threads which don't run Perl interpreters. So the front-end and the back-end can now co-exist on the same server. Practically we still need to work out the details. Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. The prototype can be written in perl and then probably better ported to C. You can use the MyApache::FilterSnoop (http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter) to trace the data propogation through filters. Of course first you need to understand the 2.0 architecture, which is discussed in details at http://perl.apache.org/docs/2.0/user/index.html (Part IV: mod_perl Handlers). As this is a new documentation please help to improve it. Especially if you have more interesting examples, than the ones I've come up with. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Philip == Philip Mak [EMAIL PROTECTED] writes: Philip Let's say you have a mod_perl page that returns a 100k document, and a Philip 28.8k modem downloads that document. Philip The mod_perl process that is serving that document will be tied up Philip until that modem finishes downloading the document, which is Philip inefficient since the mod_perl processes take up a lot of memory. A Philip lightweight front-end proxy that loads the data from the mod_perl Philip process all at once and then feeds it to the modem would save memory. Yeah, I did this to stonehenge.com about five months ago, and am now handling about 3-4 times the traffic for the same loadav. All on one machine. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL: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!
[OT] Persistant MySQL connections in Apache 2
This is really a C API thing, but I was wondering if Apache2::DBI people can help me shed some light on this... - Original Message - From: Kent Fitch To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 5:37 AM Subject: Re: [apache-modules] Persistant MySQL connections in Apache 2 Hi Issac, From: Issac Goldstand Subject: [apache-modules] Persistant MySQL connections in Apache 2 Hi all, I'm a rookie C API programmer (mod_perl was just so much *easier* most of the time :-)), and am working on coding a module to with in my front-end Apache 2/mod_proxy server. The idea of the module is to provide access to the front-end server with a list of blacklisted IPs which are stored in a MySQL database. So I'm thinking the module's child_init should open the connection to the MySQL database and then the access_handler can grab the MySQL connection from the child-pool. Yes, but beware that in a threaded Apache run-time, there could be many threads fo execution processing many requests simultaneously in your child process, so you'll have to arrange to lock the connection whilst a thread is using it and possibly have a pool of them. See Thread Safety http://httpd.apache.org/docs-2.0/developer/thread_safety.html But the problem is that I would *like* for the connections to the database be closed before the pool is simply swept clean upon destruction. I would think that that would be a good thing to do - maybe I'm wrong... Yes - you should register a cleanup function on the pool you allocate the data structures for the connection(s) from in your init. See these notes on pooling (which may be a bit 1.3-ish and hence out of date, but the ideas are relevant): http://httpd.apache.org/docs-2.0/developer/API.html#pools and see the apr_pool_cleanup_register api Kent Fitch
Re: [OT] Persistant MySQL connections in Apache 2
Issac Goldstand wrote: This is really a C API thing, but I was wondering if Apache2::DBI people can help me shed some light on this... I'm not sure what's the Apache2::DBI question, but we (Tim, Hugo, Eric at el.) have discussed the Apache::DBI for threaded apps at the last TPC and the conclusion was that we need to write a generic Perl Thread::DBI module to work with threaded Perl and then use Apache::DBI on top of it. Some of this was discussed on the dbi-dev list, but as far as I know nothing was developed so far. If you want to discuss the design, which is not trivial, and implementation, it's probably the best to do that on the dbi-dev list. - Original Message - From: Kent Fitch To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 5:37 AM Subject: Re: [apache-modules] Persistant MySQL connections in Apache 2 Hi Issac, From: Issac Goldstand Subject: [apache-modules] Persistant MySQL connections in Apache 2 Hi all, I'm a rookie C API programmer (mod_perl was just so much *easier* most of the time :-)), and am working on coding a module to with in my front-end Apache 2/mod_proxy server. The idea of the module is to provide access to the front-end server with a list of blacklisted IPs which are stored in a MySQL database. So I'm thinking the module's child_init should open the connection to the MySQL database and then the access_handler can grab the MySQL connection from the child-pool. Yes, but beware that in a threaded Apache run-time, there could be many threads fo execution processing many requests simultaneously in your child process, so you'll have to arrange to lock the connection whilst a thread is using it and possibly have a pool of them. See Thread Safety http://httpd.apache.org/docs-2.0/developer/thread_safety.html But the problem is that I would *like* for the connections to the database be closed before the pool is simply swept clean upon destruction. I would think that that would be a good thing to do - maybe I'm wrong... Yes - you should register a cleanup function on the pool you allocate the data structures for the connection(s) from in your init. See these notes on pooling (which may be a bit 1.3-ish and hence out of date, but the ideas are relevant): http://httpd.apache.org/docs-2.0/developer/API.html#pools and see the apr_pool_cleanup_register api Kent Fitch -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl and apache 2.x
Jay Thorne wrote: Are there plans to make the new mod_perl backwards compatible? I tried a few months ago to move my faily large app to apache 2.x and mod perl and far far too many things are different. I'd love to experiment with the new code base, but this lack of compatibility is a show stopper for me. I don't have the time to re-code the entire thing. Failing that, is there a way to at least get print to work? Or have later mod_perl releases fixed that? Have you read the online docs? This should answer all your questions: http://perl.apache.org/docs/2.0/user/compat/compat.html#top if something is missing/unclear/wrong please let us know. Apache::compat includes most of the back-compat subs, but some are still missing. If you find such please report to the list. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
non-internal redirect at authenticate stage in Apache 2?
Hi. In Apache 1 I used the CGI module to send out HTML to do a non-internal redirect from my PerlAuthenHandler script, once authentication had been established. But now Apache 2 / mod_perl 2 doesn't seem to like that (complains that it can't do a send_cgi_header on a null value, for exactly the same code). If anyone could suggest a method for redirecting the browser to a specified non-internal url, in Apache 2 / mod_perl 2, from a PerlAuthenHandler, I'd be really grateful. Cheers Kirk.
mod_perl and apache 2.x
Are there plans to make the new mod_perl backwards compatible? I tried a few months ago to move my faily large app to apache 2.x and mod perl and far far too many things are different. I'd love to experiment with the new code base, but this lack of compatibility is a show stopper for me. I don't have the time to re-code the entire thing. Failing that, is there a way to at least get print to work? Or have later mod_perl releases fixed that? -- Jay yohimbe Thorne [EMAIL PROTECTED] Mgr Sys Tech, Userfriendly.org
Make test failure when installing mod_perl 2.0 on Solaris 8 with Apache 2
Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: ./configure --enable-layout=Solaris --enable-perl=shared --with-mpm=prefork (as normal user) make(as normal user) make test (as root user) make install (as root user) this seems to install fine. I have then configured mod_perl as follows: perl Makefile.PL MP_AP_PREFIX=/usr/apache MP_INST_APACHE2=1 (as normal user) make (as normal user) make test (as root user) And the 'make test' fails: Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/cgihandler.t22 100.00% 1-2 apache/compat.t33 100.00% 1-3 apache/post.t 21 50.00% 2 apache/read.t 11 100.00% 1 apache/scanhdrs.t 29 7424 44 100.00% 1-4 api/send_fd.t 32 66.67% 2-3 api/sendfile.t 32 66.67% 2-3 directive/perlmodule.t 11 100.00% 1 directive/perlrequire.t11 100.00% 1 directive/setupenv.t 31 33.33% 2 filter/input_body.t22 100.00% 1-2 filter/lc.t11 100.00% 1 hooks/access.t 42 50.00% 2-3 hooks/trans.t 33 100.00% 1-3 modperl/getc.t 21 50.00% 2 modperl/readline.t 21 50.00% 2 modperl/sameinterp.t 29 742412 12 100.00% 1-12 modules/include.t 65 83.33% 1 3-6 protocol/echo.t 255 65280 32 66.67% 2-3 protocol/echo_filter.t 255 65280 32 66.67% 2-3 50 tests skipped. So, as you can see not very good. After looking at the recommended log file (t/logs/errorlog) I see the following: bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/home/software/apache _download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/lib/Apach e2 /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apache2 /export/home/software/apache_download_2_0_39/mod_perl -1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/software/apache_down load_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/p rotocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/perlmodule-vh /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/main /usr/local/lib/perl5/5.8.0/sun4-so laris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr /local/lib/perl5/site_perl) at (eval 15) line 3. [Tue Aug 20 15:01:20 2002] [error] failed to resolve handler `TestHooks::init::first' [Tue Aug 20 15:01:20 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/li b/Apache2 /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apac he2 /export/home/software/apache_downl oad_2_0_39/mod_perl-1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/ arch /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/protocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apach e_download_2_0_39/mod_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irec
Re: Naming convention for Apache 2 modules.
At 11:31 18.06.2002, Andy Wardley wrote: I've been playing around with Apache 2 and mod_perl 1.99 and considering the changes I'll need to make to Apache::Template to make it play nicely under the new world order. Given that I want to continue to support Apache::Template for v1 users, should I create another module, say Apache2::Template, or is there some preferred approach to v1/v2 compatabilities that I should consider? I've read the compat.html doc and understand that I might be able to support Apache::Template as it is with the help of the Apache2 compatability module. However, I'm sure there are some parts, server/dir merging in particular (which seem to be broken in v1 anyway), which are going to need new implementations for v2, so I figure it's probably worth forking the codebase sooner rather than later. What about making the 2.0 module follow the conventions I posted about earlier? Something like Apache::Framework::Template? -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Naming convention for Apache 2 modules.
At 13:26 18.06.2002, Stas Bekman wrote: Andy Wardley wrote: I've been playing around with Apache 2 and mod_perl 1.99 and considering the changes I'll need to make to Apache::Template to make it play nicely under the new world order. Given that I want to continue to support Apache::Template for v1 users, should I create another module, say Apache2::Template, or is there some preferred approach to v1/v2 compatabilities that I should consider? I've read the compat.html doc and understand that I might be able to support Apache::Template as it is with the help of the Apache2 compatability module. However, I'm sure there are some parts, server/dir merging in particular (which seem to be broken in v1 anyway), which are going to need new implementations for v2, so I figure it's probably worth forking the codebase sooner rather than later. No Andy, no need to rename, you can either maintain the two in one module (if it's not too messy, which is the case if you have a lot of C) or just two different versions which will install themselves into different dirs. Here are some preliminary notes discussing these issues. http://perl.apache.org/release/docs/2.0/devel/porting_from_1.x/porting_from_1.x.html Feel free to help improving on these. Of course the MP_INST_APACHE2=1 mechanism needs to become available to to other module writers. Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Naming convention for Apache 2 modules.
[CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? Thanks! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Naming convention for Apache 2 modules.
On 2002.06.18 09:57 Stas Bekman wrote: [CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? An alternative approach could involve placing the functionality specific to mod_perl 2.0 in a sub-module, then conditionally importing that submodule depending on the value of $Apache::Registry::VERSION. Ian
Re: Naming convention for Apache 2 modules.
Ian D. Stewart wrote: On 2002.06.18 09:57 Stas Bekman wrote: [CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? An alternative approach could involve placing the functionality specific to mod_perl 2.0 in a sub-module, then conditionally importing that submodule depending on the value of $Apache::Registry::VERSION. This is not the case for the complex modules involving C, XS, custom directives and lots of code. As a module author I'd rather have a separate code base without gazillions of #ifdefs and perl side version checking. It's very unlikely that you will be able to extract mod_perl 2.0 specific functionality into a sub-module, because most of the Apache:: modules are using the mod_perl 2.0 API everywhere in the code. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache 2 mod_perl 2 Apache::DBI
On Sun, 9 Jun 2002, Yuri A. Kabaenkov wrote: Hello, How can i install Apache::DBI module with mod_perl 2? I'm not sure what the current status of this is, but see the discussion of Apache::DBIPool at http://perl.apache.org/release/docs/2.0/user/overview/overview.html. best regards, randy kobes
apache 2 mod_perl 2 Apache::DBI
Hello, How can i install Apache::DBI module with mod_perl 2? -- Best regards, Yuri mailto:[EMAIL PROTECTED]
Re: mod_perl 2 apache 2?
Michael Wojcikiewicz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone tried getting mod_perl to work in Apache v2 (the latest beta?)... Just a quick try resulted in mod_perl2 trying to compile against apache 1.3.20... Wasnt mod_perl v2 supposed to be for Apache v2?... modperl 2.x is in development and if you want to play with it, you have to read *its* docs to figure out how to install it. modperl 1.x won't work with httpd 2.x. So either use 1x's or 2x's but don't mix the two. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
mod_perl 2 apache 2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone tried getting mod_perl to work in Apache v2 (the latest beta?)... Just a quick try resulted in mod_perl2 trying to compile against apache 1.3.20... Wasnt mod_perl v2 supposed to be for Apache v2?... Michael Wojcikiewicz Perl Developer - Perl Pimps W: http://www.perlpimps.com/ E: [EMAIL PROTECTED] P: (514) 235-7900 F: (508) 546-0398 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7w1JOcQrQUtU6ZNoRAnd1AKDScL9pkf9GX2wPeoeTrRZ6bbwvyQCgsVE1 POR2lXWV7hak1Nf6D0nhquY= =2TLd -END PGP SIGNATURE-
Re: Apache 2 opportunity
On Sun, 2 Jul 2000, Francesco Pasqualini wrote: I think in the current version of modperl there is an important feature missing. At this time is not possible to share resources between apache childs and so we can not use "really" persistent DBI coneection. What I intend is the possibility to store a DBI connection in the $Session hash (Apache::ASP or Apache::Session). In this way we can start a DB connection for each user session and we can have different application upon differnet DB. The connection is started when the user session start, is maintenied in memory (in the apache main process ?),it is visible to the apache childs (threads) and is destroied at session end. With the efforts (syntax tree sharing between threads) necessary to port modperl to apache 2, will be possible to implement such a feature ? it will be possible to share db connections between threads. but 2.0 is hybrid, there are still multiple processes, you cannot share db connections between them, without something like DBD::Proxy.
Apache 2 opportunity
I think in the current version of modperl there is an important feature missing. At this time is not possible to share resources between apache childs and so we can not use "really" persistent DBI coneection. What I intend is the possibility to store a DBI connection in the $Session hash (Apache::ASP or Apache::Session). In this way we can start a DB connection for each user session and we can have different application upon differnet DB. The connection is started when the user session start, is maintenied in memory (in the apache main process ?),it is visible to the apache childs (threads) and is destroied at session end. With the efforts (syntax tree sharing between threads) necessary to port modperl to apache 2, will be possible to implement such a feature ? Thanks Francesco Pasqualini
