cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
stas2003/01/21 19:19:43
Modified:.Changes
src/modules/perl modperl_io.c modperl_io.h
t/modperl .cvsignore
todo api.txt
xs/Apache/RequestIO Apache__RequestIO.h
xs/maps modperl_functions.map
xs/tables/current/ModPerl FunctionTable.pm
Added: t/response/TestModperl request_rec_tie_api.pm
Log:
- expose useful macros from modperl_io.c via modperl_io.h
- add $r-FILENO implementation
- add a test
Revision ChangesPath
1.107 +2 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.106
retrieving revision 1.107
diff -u -r1.106 -r1.107
--- Changes 20 Jan 2003 07:54:52 - 1.106
+++ Changes 22 Jan 2003 03:19:43 - 1.107
@@ -10,6 +10,8 @@
=item 1.99_09-dev
+Add $r-FILENO implementation [Stas]
+
Apache::Test: Support NoAutoConfig /NoAutoConfig blocks in .pm
files, so we can have a full manual control over generated config
sections. These sections are fully parsed and variables are
1.1 modperl-2.0/t/response/TestModperl/request_rec_tie_api.pm
Index: request_rec_tie_api.pm
===
package TestModperl::request_rec_tie_api;
use strict;
use warnings FATAL = 'all';
use Apache::RequestIO ();
use Apache::Test;
use Apache::TestUtil;
use Apache::Const -compile = 'OK';
sub handler {
my $r = shift;
plan $r, tests = 1;
ok t_cmp(fileno(STDOUT), $r-FILENO(), FILENO);
return Apache::OK;
}
1;
1.9 +0 -13 modperl-2.0/src/modules/perl/modperl_io.c
Index: modperl_io.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- modperl_io.c 24 Mar 2002 02:41:29 - 1.8
+++ modperl_io.c 22 Jan 2003 03:19:43 - 1.9
@@ -1,18 +1,5 @@
#include mod_perl.h
-/*
- * bleedperl change #11639 switch tied handle magic
- * from living in the gv to the GvIOp(gv), so we have to deal
- * with both to support 5.6.x
- */
-#if ((PERL_REVISION == 5) (PERL_VERSION = 7))
-# define TIEHANDLE_SV(handle) (SV*)GvIOp((SV*)handle)
-#else
-# define TIEHANDLE_SV(handle) (SV*)handle
-#endif
-
-#define dHANDLE(name) GV *handle = gv_fetchpv(name, TRUE, SVt_PVIO)
-
#define TIEHANDLE(handle,r) \
modperl_io_handle_tie(aTHX_ handle, Apache::RequestRec, (void *)r)
1.2 +13 -0 modperl-2.0/src/modules/perl/modperl_io.h
Index: modperl_io.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- modperl_io.h 5 May 2001 22:06:41 - 1.1
+++ modperl_io.h 22 Jan 2003 03:19:43 - 1.2
@@ -1,6 +1,19 @@
#ifndef MODPERL_IO_H
#define MODPERL_IO_H
+/*
+ * bleedperl change #11639 switch tied handle magic
+ * from living in the gv to the GvIOp(gv), so we have to deal
+ * with both to support 5.6.x
+ */
+#if ((PERL_REVISION == 5) (PERL_VERSION = 7))
+# define TIEHANDLE_SV(handle) (SV*)GvIOp((SV*)handle)
+#else
+# define TIEHANDLE_SV(handle) (SV*)handle
+#endif
+
+#define dHANDLE(name) GV *handle = gv_fetchpv(name, TRUE, SVt_PVIO)
+
#define IoFLUSH_off(gv) \
IoFLAGS(GvIOp((gv))) = ~IOf_FLUSH
1.11 +1 -0 modperl-2.0/t/modperl/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/modperl-2.0/t/modperl/.cvsignore,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- .cvsignore22 Oct 2002 15:13:22 - 1.10
+++ .cvsignore22 Jan 2003 03:19:43 - 1.11
@@ -10,3 +10,4 @@
methodobj.t
method.t
setauth.t
+request_rec_tie_api.t
1.30 +1 -1 modperl-2.0/todo/api.txt
Index: api.txt
===
RCS file: /home/cvs/modperl-2.0/todo/api.txt,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- api.txt 6 Dec 2002 16:19:36 - 1.29
+++ api.txt 22 Jan 2003 03:19:43 - 1.30
@@ -3,7 +3,7 @@
--
tied filehandle interface:
- -CLOSE, OPEN, EOF, TELL, SEEK, FILENO
+ -CLOSE, OPEN, EOF, TELL, SEEK
-READLINE - proper implementation (see comment in Apache::compat)
$r-finfo:
1.31 +7 -0
cvs commit: modperl-2.0/t/error push_handlers.t
stas2003/01/21 23:00:29
Modified:t/error push_handlers.t
Log:
use the new under_construction test to print a descriptive skip reason
Revision ChangesPath
1.3 +1 -1 modperl-2.0/t/error/push_handlers.t
Index: push_handlers.t
===
RCS file: /home/cvs/modperl-2.0/t/error/push_handlers.t,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- push_handlers.t 21 Jan 2003 06:30:23 - 1.2
+++ push_handlers.t 22 Jan 2003 07:00:29 - 1.3
@@ -7,7 +7,7 @@
# XXX: the misuse of push_handlers exercised by this test is different
# at least on FreeBSD, so it fails, skip for now.
-plan tests = 1, have { ignore = sub { 0 } };
+plan tests = 1, under_construction;
my $location = /TestError::push_handlers;
my $expected = ok;
cvs commit: modperl-2.0 Changes
stas2003/01/21 23:02:14 Modified:.Changes Log: log the recent changes Revision ChangesPath 1.109 +5 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.108 retrieving revision 1.109 diff -u -r1.108 -r1.109 --- Changes 22 Jan 2003 06:12:42 - 1.108 +++ Changes 22 Jan 2003 07:02:14 - 1.109 @@ -10,6 +10,11 @@ =item 1.99_09-dev +Apache::Test: support two new shortcuts for skip functionality: + - have_threads: checks whether both Apache and Perl support threads + - under_construction: to print a consistent/clear skip reason +[Stas] + OPEN, CLOSE and FILENO implementation for Apache::RequestRec [Stas] Apache::Test: Support NoAutoConfig /NoAutoConfig blocks in .pm
Error message: setup_inherited_listeners ?
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Hello, I hope this is going to the users list Apache/1.3.14 (Win32) mod_perl/1.27.01-dev running... [crit] (109)The pipe has been ended: setup_inherited_listeners: Unable to read socket data from parent. Could someone please help me understand what this means? I only get it when loading a module, which points to my error, but an identical setup on another machine has no problems: on both machines, the scripts compile and execute from the command line, and the logs shows no more information than the above, except to say that the start-up script I use is executed twice before any connection. On the second connect, flop. I've looked in the mod_perl Guide, the mod_perl site, this list's archives, but found no reference to this error. Am I missing something? Any help appreciated - thanks, Lee -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPi0UvadrfekeF/QBAQGY9gQAltTcKbEj0aFjUleCAEtxwrbCJGUkM3qu cjcWfj7lcdEOCbM5tWuWxy9WInsTgyEUXKhvhaC1BC2M/gRlq0ev7pVhh/fKKdvc GtbW96jxl/77rUNO0kO0En0ehayunQazVnvMCJyZqalYg+FK/xIzlB6UZzCxGS2P 9xe7hOuKstc= =ySQ+ -END PGP SIGNATURE-
[OT] MLDBM Size Limit??
Guys,
Sorry this is a little off topic... Is there a size limit on DBM's? (Or
Linux files for that matter.. )
I've thrown some details of my box/code below..
Thing is I'm getting a write error and it seems to always happen when
the DBM gets to 2.0Gb .. (you may think I'm mad for trying to make 2G
DBM's - but they don't usually get more than a couple of 100k - it's
just a big site.. Honest ;-)
Anyway - if there's anyone with similar experience or anyone has some
advice for me it would be appreciated..
Thanks,
J.
Here are the details..
Error :
write error at /usr/local/lib/perl5/site_perl/5.8.0/MLDBM.pm line 161.
Line to which it's reffering :
$s-{DB}-STORE($k, $v);
My use of MLDBM..
use GDBM_File;
use MLDBM qw(GDBM_File Storable);
Perl-v
This is perl, v5.8.0 built for i686-linux
uname-a
Linux hope 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
Jim Morrison
_
Technology Development Partner
Isotope LLP
9, 2 Laura Place
Bath, BA2 4BH
UK
+44 (0) 1225 444674
+44 (0) 7940 937822
www.mediaisotope.com
Re: Error message: setup_inherited_listeners ?
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 For the record My problem, below, came about because of some small runtime erros. It was not caught by the usual means documented in the Guide (etc), and I have been unable to find any reference to the error message outside of the httpd source code. Lee On Tuesday, January 21, 2003 at 10:37:00 AM, you wrote: LG Hello, LG I hope this is going to the users list LG Apache/1.3.14 (Win32) mod_perl/1.27.01-dev running... LG [crit] (109)The pipe has been ended: setup_inherited_listeners: Unable LG to read socket data from parent. LG Could someone please help me understand what this means? LG I only get it when loading a module, which points to my error, but an LG identical setup on another machine has no problems: on both machines, LG the scripts compile and execute from the command line, and the logs LG shows no more information than the above, except to say that the LG start-up script I use is executed twice before any connection. On the LG second connect, flop. LG I've looked in the mod_perl Guide, the mod_perl site, this list's LG archives, but found no reference to this error. LG Am I missing something? LG Any help appreciated - thanks, LG Lee - -- Cheers Leemailto:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPi1cYqdrfekeF/QBAQEtQgP8DFCe9Xa4grebc0tEYouv/nIONamQKt8V idDPUVWXBloQ+b23wD9Lj3+yHodE7tZKKRCwWxW3089iJ3S832ikq3YImTYmlLQ6 3kGIXLnnmmFGil6qZIOw8X5xgQyxbYCVsp/JezUXTdtLxoRub0dq2S/FOqFknE5z 1LI/4i9KVD8= =8JyP -END PGP SIGNATURE-
Re: [OT] MLDBM Size Limit??
Hi there, On Tue, 21 Jan 2003, Jim Morrison [Mailinglists] wrote: Sorry this is a little off topic... Is there a size limit on DBM's? (Or Linux files for that matter.. ) [snip] Thing is I'm getting a write error and it seems to always happen when the DBM gets to 2.0Gb .. [snip] Linux hope 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown I only have gdbm, which doesn't have at least some of the dbm restrictions, so I don't know about dbm files. There are some cautions about dbm files in the mod_perl Guide. For Linux files it depends on the filesystem you're using and how it was initialized. For example I use ext2 (most will), and in my copy of the documentation (it's for 2.4.19) it gives a list of file and filesystem sizes for different block sizes. (I won't post the whole thing as it's over 17kBytes:). -- Filesystem block size: 1kB2kB4kB8kB File size limit: 16GB 256GB 2048GB 2048GB Filesystem size limit: 2047GB 8192GB16384GB32768GB There is a 2.4 kernel limit of 2048GB for a single block device, so no filesystem larger than that can be created at this time. There is also an upper limit on the block size imposed by the page size of the kernel, so 8kB blocks are only allowed on Alpha systems (and other architectures which support larger pages). -- Check out linux-2.4.7/Documentation/filesystems/ext2.txt or whatever you have on your system. You might want to consider using gdbm, your data could then be as large as you want according to the manpage... 73, Ged.
Re: [mp2] e-Commerce
Hi, You know I was all ready on my dev box to start messing around with apache2, when we had a major evil thing happen on our fancy server. So my dev box had to become our server. And because I have not had any personal experence with apache 2, I converted everthing back to 1.x on the dev box. But you are right of course, I should not just assume because of hearsay that Apache2 will be faster. But between the threading, and the file cache module I *hope* it is faster :) Here is one kind of old thing I found on google: http://www.zend.com/lists/php-dev/200202/msg01675.html They are focused on PHP, but it seems like there might be some problems with the DSO only stuff. Weird that it is not easier to find stuf, I would have expected millions of hits on google for this. I will definatly will work on a better test with static and mod_perl once we get our fancy server back and post it to the list. But I can't believe someone on this list hasn't done that already. Thanks, Eric At 06:09 PM 1/21/03 +1100, Stas Bekman wrote: Perrin Harkins wrote: Eric Frazier wrote: On that note, how about just using Apache2 for the proxy front end, and mod_perl /apache 1.x for the back end? I have wanted to try to avoid the thttpd stuff for images and from what I have heard about apache2 it can handle static pages a lot faster than the 1.x did. You really should be able to get more than enough performance out of 1.x for static files, unless you are using very old hardware. We used a slim 1.x build with mod_proxy, mod_ssl, and mod_rewrite for all of our static files at eToys and it ran like a champ. It's true that both thttpd and apache 2 have better performance, Where did you see the benchmarks showing that Apache 2.0 has a better performance than 1.3? Apache 2.0 should scale better when threads are used (on platforms where threads are faster than processes) and it's definitely a must for win32, but I haven't seen any numbers other than some reports to the httpd-dev list, so I don't know. Also Apache 2.0 provides features like filters, which were almost impossible with 1.3, though how things get slowed down when these are used is a question. Please notice that I'm not saying that 2.0 is slower, I'm just asking to see the numbers ;) __ 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 (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: [OT] MLDBM Size Limit??
On Tue, Jan 21, 2003 at 02:37:02PM +, Ged Haywood wrote: Hi there, On Tue, 21 Jan 2003, Jim Morrison [Mailinglists] wrote: Sorry this is a little off topic... Is there a size limit on DBM's? (Or Linux files for that matter.. ) [snip] Thing is I'm getting a write error and it seems to always happen when the DBM gets to 2.0Gb .. [snip] Linux hope 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown Actually, I finally had to upgrade to 2.4.17 (or .19) and custom compile the kernel to get this to work. I had a similar problem with mysql files being 12GB. I forget exactly the steps, but if you hunt around in the kernel configurator I'm sure it'll show up... :) Rob
Re: [mp2]make test fails
On Tue, 21 Jan 2003 16:05:05 +1100 Stas Bekman [EMAIL PROTECTED] wrote: Steve Glaus wrote: On Mon, 20 Jan 2003 11:29:01 -0500 [EMAIL PROTECTED] wrote: Hi, I'm trying to build mod_perl2 with threads enabled. I recompiled apache with the worker mpm, built mod_perl which seemd to build fine.. however, when I go to 'make test' it gives me the following error: Cannot load /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so into server: /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so: undefined symbol: Perl_Ipatchlevel_ptr!!! what's the output of: nm /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so should be something like: U Perl_Ipatchlevel_ptr which is an unresolved symbol, which gets resolved when libperl.so is loaded. To find out which perl library you have linked against, do: ldd modules/mod_perl.so |grep perl libperl.so = /home/stas/perl/blead-ithread/lib/5.9.0/i686-linux-thread-multi/CORE/libperl.so (0x4002e000) Now you can check whether the symbol is there. in my case: nm /home/stas/perl/blead-ithread/lib/5.9.0/i686-linux-thread-multi/CORE/libperl.so |grep Perl_Ipatch 0011fa41 T Perl_Ipatchlevel_ptr Chances are that you are linking against the wrong perl library, which will explain the resolving problem. Ok, I know we're probably going of topic here, but I'll ask anyways.. I did what you said...the symbol wasn't there in lipperl.so. So. I rebuilt my perl, rebuilt the library, rebuilt my perl again.. I only have one perl library on my system.. It still fails. This is a pretty new version of the perl library, so is it possible that I need an older one? (libperl-5.8.0). I'm at a bit of a loss as to where to go from here. Thx. Steve
Re: [mp2] e-Commerce
On Tue, 21 Jan 2003, Perrin Harkins wrote:
Eric Frazier wrote:
On that note, how about just using Apache2 for the proxy front end, and
mod_perl /apache 1.x for the back end? I have wanted to try to avoid the
thttpd stuff for images and from what I have heard about apache2 it can
handle static pages a lot faster than the 1.x did.
You really should be able to get more than enough performance out of 1.x
for static files, unless you are using very old hardware. We used a
slim 1.x build with mod_proxy, mod_ssl, and mod_rewrite for all of our
static files at eToys and it ran like a champ. It's true that both
thttpd and apache 2 have better performance, but web server performance
on static files is almost irrelevant on today's hardware because you
fill your bandwidth up long before anything else becomes an issue.
Hmm, I think it all depends on the application. It's true that hardware
costs have declined since The Days, but you still don't have unlimited
RAM. At ValueClick we were delivering 100 million+ gif images a day, after
doing all the hard stuff with mod_perl servers, and it was just not
possible to keep up with apache 1.3x. We wound up having just one machine
running thttpd serving all those images for 50 or a hundred webservers.
So sometimes I believe it's called for.
- nick
Nick Tonkin {|8^)
Re: [mp2] e-Commerce
Nick Tonkin wrote: Hmm, I think it all depends on the application. It's true that hardware costs have declined since The Days, but you still don't have unlimited RAM. True, there is an upper limit on per-machine scalability with a multi-process server and thttpd would do better there if the network connection is not already saturated. In our case we benchmarked thttpd vs. a stripped apache 1.x and the performance was so close that we decided to go with the simpler route of using apache, which gave us SSL for images and the ability to run a single server for proxy and static page requests. It also made it easy to set Expires tags on images. One possible factor in our good apache performance is the high locality of access for our static files. There was a very good chance that any requested file would already be cached in RAM. ValueClick was probably just the opposite. - Perrin
[DIGEST] mod_perl digest 2002/12/30
-- mod_perl digest December 30, 2002 - January 19, 2003 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o available mod_perlers o mailing list highlights o conferences o links mod_perl status o mod_perl - stable: 1.27 (released June 1, 2002) [1] - development: 1.27_01-dev [2] o Apache - stable: 1.3.27 (released October 3, 2002) [3] - development: 1.3.28-dev [4] o mod_perl 2.0 - beta: 1.99_08 (released January 10, 2002) [5] - development: (from cvs) [6] o Apache 2.0 - stable: 2.0.44 (released January 18, 2003) [7] o Perl - stable: 5.8.0 (released July 18, 2002) [8] - development: none [9] module announcements o Apache::CompressClientFixup 0.05 - Used with Apache::Dynagzip to avoid compression for some buggy clients [10] o Apache::DBI 0.90_02 - Development release of Apache::DBI that works with mod_perl 2.0 [11] o Apache::Dynagzip 0.09 - Dynamic gzip compression of outbound stream [12] o Bricolage 1.4.6 - Enterprise content management system [13] o Bricolage Devel 1.5.0 - Development version of Bricolage [14] module rfcs o Modules to create dynamic websites [15] mailing list highlights o New version of mod_perl (1.99_08) [16] o OSCon ideas (and other related thoughts) [17] + MVC talk [18] + missing proceedings [19] o Development techniques - anything more advanced than `print' and `tail'? [20] o Load balancers [21] o Bricolage on _Online Tonight_ [22] conferences o OsCON 2003 Call for Proposals [23] o YAPC::NA Call for Proposals [24] links o The Apache/Perl Integration Project [25] o mod_perl documentation [26] o Apache modules on CPAN [27] o _Writing Apache Modules with Perl and C_ homepage [28] o _mod_perl Developer's Cookbook_ homepage [29] o Other mod_perl-related books [30] o mod_perl news and advocacy [31] o mod_perl list archives - modperl@ [32] - dev@ [33] - docs-dev@ [34] - advocacy@ [35] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://cvs.apache.org/snapshots/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/README.html [10] http://mathforum.org/epigone/modperl/swyrzhixkhax [11] http://mathforum.org/epigone/modperl/wonfoisperd [12] http://mathforum.org/epigone/modperl/rehspeufroi [13] http://mathforum.org/epigone/modperl/veetroysnah [14] http://mathforum.org/epigone/modperl/tromghandthong [15] http://mathforum.org/epigone/modperl/clayvexblil [16] http://mathforum.org/epigone/modperl/yungsliwand [17] http://mathforum.org/epigone/modperl/clonwoythah http://mathforum.org/epigone/modperl/chixphimkerm http://mathforum.org/epigone/modperl/bonstraxblei http://mathforum.org/epigone/modperl/roapingrald [18] http://mathforum.org/epigone/modperl/toyspixgrox [19] http://mathforum.org/epigone/modperl/lenphembril [10] http://mathforum.org/epigone/modperl/whamfrankhil [21] http://mathforum.org/epigone/modperl/wheiremwom [22] http://mathforum.org/epigone/modperl/clelsheldrau [23] http://conferences.oreillynet.com/os2003/ http://conferences.oreillynet.com/cs/os2003/create/e_sess [24] http://www.yapc.org/America/index.shtml http://www.yapc.org/America/cfp.shtml [25] http://perl.apache.org/ [26] http://perl.apache.org/docs/ [27] http://www.cpan.org/modules/by-module/Apache/ [28] http://www.modperl.com/ [29] http://www.modperlcookbook.org/ [30] http://perl.apache.org/docs/offsite/books.html [31] http://www.take23.org/ [32] http://perl.apache.org/maillist/modperl.html#Searchable_Archives [33] http://perl.apache.org/maillist/dev.html#Searchable_Archives [34] http://perl.apache.org/maillist/docs-dev.html#Searchable_Archives [35] http://perl.apache.org/maillist/advocacy.html#Searchable_Archives
Re: [mp2] e-Commerce
Stas Bekman wrote: Where did you see the benchmarks showing that Apache 2.0 has a better performance than 1.3? All over! Joshua's numbers from this list: http://marc.theaimsgroup.com/?l=apache-modperlm=103238123915307w=2 Some good graphs, including thttpd: http://www.zeuscat.com/andrew/work/aprbench/ Someone's random benchmark from Google: http://www.vomjom.com/docs/apache_benchmark.php I've seen other random posts too, which I can't find at the moment. Note that ZDNet found no improvement over 1.x on Linux when they benchmarked it, but it was version 2.035 and there could be other factors as well. http://www.eweek.com/article2/0,3959,15300,00.asp - Perrin
ANNOUNCE: Loggerithim 6.1.4
http://loggerithim.sourceforge.net Loggerithim is monitoring package for Linux and Solaris (with early support for OS X and Win32). It allows you to collect metrics from your hosts and analyze them with graphs and whatnot. You can also set thresholds for proactively spotting problems. Modules can be written to supplement the stock data collection. Loggerithim is mod_perl (obviously) and PostgreSQL. Agents written in C collect data and send it to the box that runs Loggerithim. This is the first time I've announced Loggerithim somewhere other than Freshmeat. I'd greatly appreciate feedback from the mod_perl crowd. I'm impressed with the work of others on the list and I welcome your opinions. Expect rough edges and broken pieces as very few people have run it outside of my office. Mailing lists are available for anyone interested, see the website. Thanks! Cory 'G' Watson http://gcdb.spleck.net
Testing
Hi there, I am new to this list and new to mod_perl in general, so I hope the more experienced folks will be able to help me. :) We are starting to test our perl code running under mod_perl. We did go through the porting guide and did everything that was receommended. I am interested in how people setup their Apache 1.3.x servers to run mod_perl'able code. Not, how to get mod_perl to run something, we do that with rewrite rules. I am more interested in config settings that control for performance and stability. I am also very concerned about testing. How do you test a mod_perl system to make sure there is no memory corruption from one instance of an app to another. I have thought about setting MaxServers to 1 and MaxClients to 1, to force the same compiled perl code to be reused, but I am not sure that is agood test. Is there any documentation on testing a mod_perl app? I have yet to find anything. Again, I appreciate the help and I hope to become an active member of this list. Regards...Michael --- IT Director/System Admin Globalware Solutions Redwood City, CA. - Original Message - From: Ged Haywood [EMAIL PROTECTED] To: Jim Morrison [Mailinglists] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 21, 2003 6:37 AM Subject: Re: [OT] MLDBM Size Limit?? Hi there, On Tue, 21 Jan 2003, Jim Morrison [Mailinglists] wrote: Sorry this is a little off topic... Is there a size limit on DBM's? (Or Linux files for that matter.. ) [snip] Thing is I'm getting a write error and it seems to always happen when the DBM gets to 2.0Gb .. [snip] Linux hope 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown I only have gdbm, which doesn't have at least some of the dbm restrictions, so I don't know about dbm files. There are some cautions about dbm files in the mod_perl Guide. For Linux files it depends on the filesystem you're using and how it was initialized. For example I use ext2 (most will), and in my copy of the documentation (it's for 2.4.19) it gives a list of file and filesystem sizes for different block sizes. (I won't post the whole thing as it's over 17kBytes:). -- Filesystem block size: 1kB2kB4kB8kB File size limit: 16GB 256GB 2048GB 2048GB Filesystem size limit: 2047GB 8192GB16384GB32768GB There is a 2.4 kernel limit of 2048GB for a single block device, so no filesystem larger than that can be created at this time. There is also an upper limit on the block size imposed by the page size of the kernel, so 8kB blocks are only allowed on Alpha systems (and other architectures which support larger pages). -- Check out linux-2.4.7/Documentation/filesystems/ext2.txt or whatever you have on your system. You might want to consider using gdbm, your data could then be as large as you want according to the manpage... 73, Ged.
[mp2] Apache::RequestRec, IPC::Open[23] problem
Hi,
The script below under mod_perl 1.99_08 (ModPerl::Registry), gives me
this:
Can't locate object method FILENO via package
Apache::RequestRec at /usr/lib/perl5/5.8.0/IPC/Open3.pm line 196.
A real world example of a script that has these problems is the W3C
Markup Validator,
http://dev.w3.org/cvsweb/validator/httpd/cgi-bin/check?rev=1.200.2.79.
The validator works under mod_perl 1, and I guess the test script would
as well (I'm unable to verify that at the moment, though). Maybe a
mod_perl 2 bug/missing feature?
My installation is Red Hat 8.0, Apache 2.0.40, mod_perl 1.99_08 and Perl
5.8.0. The test script:
use IPC::Open2 qw(open2);
use IO::File ();
my $in = IO::File-new_tmpfile();
my $out = IO::File-new_tmpfile();
print $in foobar\n;
seek $in, 0, 0;
print Content-Type: text/plain\n\n;
my $pid = open2($out, $in, 'tee');
undef $in;
waitpid $pid, 0;
seek $out, 0, 0;
while ($out) {
print;
}
undef $out;
Cheers,
--
\/ille Skyttä
ville.skytta at iki.fi
Re: Testing
Michael Hyman wrote: I am interested in how people setup their Apache 1.3.x servers to run mod_perl'able code. Not, how to get mod_perl to run something, we do that with rewrite rules. I am more interested in config settings that control for performance and stability. There is lots of documentation about performance tuning in the on-line documentation. http://perl.apache.org/docs/1.0/guide/performance.html is a good place to look. I am also very concerned about testing. How do you test a mod_perl system to make sure there is no memory corruption from one instance of an app to another. What do you mean by memory corruption? The only sharing that happens between processes is what your OS does magically through copy-on-write. Is there any documentation on testing a mod_perl app? I have yet to find anything. There is plenty about this in the on-line docs too. See http://perl.apache.org/docs/general/testing/testing.html. - Perrin
Re: [mp2]make test fails
Steve Glaus wrote: [...] Ok, I know we're probably going of topic here, but I'll ask anyways.. You can't run mod_perl, so it's pretty ontopic. I did what you said...the symbol wasn't there in lipperl.so. So. I rebuilt my perl, rebuilt the library, rebuilt my perl again.. I only have one perl library on my system.. It still fails. This is a pretty new version of the perl library, so is it possible that I need an older one? (libperl-5.8.0). I'm at a bit of a loss as to where to go from here. That means one thing: you use the perl include files from the new build, however you link against another library. Does your newly rebuilt library has this symbol defined? __ 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: [mp2] e-Commerce
Perrin Harkins wrote: Stas Bekman wrote: Where did you see the benchmarks showing that Apache 2.0 has a better performance than 1.3? All over! Thanks Perrin. [...] Some good graphs, including thttpd: http://www.zeuscat.com/andrew/work/aprbench/ It shows that threaded mpm's throughput is worse than preforked, which sounds dubious unless things were broken (blocking mutexes). Hopefully someone can run a benchmark on more updated versions of Apache. __ 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: ANNOUNCE: Loggerithim 6.1.4
Cory 'G' Watson wrote: http://loggerithim.sourceforge.net Loggerithim is monitoring package for Linux and Solaris (with early [...] It will be added to http://perl.apache.org/products/products.html on the next update. p.s. If you have written useful apps running under mod_perl and they aren't listed on perl.apache.org let us know. __ 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: [Slightly OT] [mp2] e-Commerce
Hey Stas, PHSome good graphs, including thttpd: PHhttp://www.zeuscat.com/andrew/work/aprbench/ SBIt shows that threaded mpm's throughput is worse than preforked, which SBsounds dubious unless things were broken (blocking mutexes). Hopefully SBsomeone can run a benchmark on more updated versions of Apache. There were in fact some known problems with the worker MPM in the early versions of Apache 2. There was some discussion on the Apache developers mailing list about this in April/May 2002. I'd really like to run my benchmarks on a current version of Apache... maybe in my copious free time... sigh. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: [mp1] Partial success working on Tru64/DSO
(... revisiting old thread about my problems with compiling
apache/mod_perl as DSO on Tru64 unix)
My problem is still not solved but I get it up to the point where it
probably lies in some customary modules (which does not behave
correctly when unloaded/reloaded) and is not directly related to
apache/mod_perl.
As I got the minimal success (some simple mod_perl application
worked), I report here the way I compiled perl/apache/mod_perl in
that case. Maybe it will help someone in similar situation.
Below I cite the main parts of the script I used (with unnecessary
details omitted):
WORK_DIR=$HOME/tools_src
DIST_DIR=$HOME/DOWNLOAD
INST_DIR=$HOME/tools
PERL_INST_DIR=$INST_DIR/perl
APACHE_INST_DIR=$INST_DIR/apache
PERL_VERSION=perl-5.6.1
APACHE_VERSION=apache_1.3.27
MOD_PERL_VERSION=mod_perl-1.27
LIBAPREQ_VERSION=libapreq-1.0
DIGEST_MD5_VERSION=Digest-MD5-2.20
MIME_BASE64_VERSION=MIME-Base64-2.12
# ... cut a lot of other modules which are out-of-topic here
#
unpack() {
if [ -d $1 ]; then
rm -rf $1
fi
echo -n Unpacking $1...
gunzip -c $DIST_DIR/$1.tar.gz | tar xf -
echo done
}
#
if [ ! -d $WORK_DIR ]; then
mkdir -p $WORK_DIR
fi
if [ ! -d $INST_DIR ]; then
mkdir -p $INST_DIR
fi
#
cd $WORK_DIR
unpack $PERL_VERSION
cd $PERL_VERSION
# Some commments:
# -Uinstallusrbinperl in my case I use customary install directory
# -Uuseshrplib there is a makefile problem and compilation error
# when we define it (which we try to patch below, so please
# experiment if you like)
# -Uusemymalloc on 64bit platforms it is recommended according to some docs
# -Ubincompat5005 we don't want coredumps caused by name conflicts
# of malloc/free
# -Dusemultiplicity it helps a bit with DSO reloading
sh Configure -des -Dprefix=$PERL_INST_DIR -Uinstallusrbinperl \
-Uuseshrplib -Uusemymalloc -Ubincompat5005 \
-Dusemultiplicity
make
make test
make install
# don't forget it when installing outside defaults
PATH=$PERL_INST_DIR/bin:$PATH; export PATH
#
build_module() {
MOD=$1
cd $WORK_DIR
unpack $MOD
cd $WORK_DIR/$MOD
perl Makefile.PL $2 $3 $4 $5 $6 $7 $8 $9
make
make test
make install
}
build_module $DIGEST_MD5_VERSION
build_module $MIME_BASE64_VERSION
# ... cut others ...
#
unpack $APACHE_VERSION
unpack $MOD_PERL_VERSION
cd $WORK_DIR/$MOD_PERL_VERSION
perl Makefile.PL $PERL_MOD_DBG $PLTRACE \
APACHE_SRC=../$APACHE_VERSION/src \
APACHE_PREFIX=$APACHE_INST_DIR \
USE_APACI=1 \
USE_DSO=1 \
DO_HTTPD=1 \
ALL_HOOKS=1 \
EVERYTHING=1 \
APACI_ARGS=--enable-module=so,\
--prefix=$APACHE_INST_DIR,\
--enable-module=access,--enable-shared=access,\
--enable-module=actions,--enable-shared=actions,\
--enable-module=alias,--enable-shared=alias,\
--enable-module=asis,--enable-shared=asis,\
--enable-module=auth,--enable-shared=auth,\
--enable-module=auth_anon,--enable-shared=auth_anon,\
--enable-module=auth_db,--enable-shared=auth_db,\
--enable-module=auth_dbm,--enable-shared=auth_dbm,\
--enable-module=autoindex,--enable-shared=autoindex,\
--enable-module=cern_meta,--enable-shared=cern_meta,\
--enable-module=cgi,--enable-shared=cgi,\
--enable-module=digest,--enable-shared=digest,\
--enable-module=dir,--enable-shared=dir,\
--enable-module=env,--enable-shared=env,\
--enable-module=example,--enable-shared=example,\
--enable-module=expires,--enable-shared=expires,\
--enable-module=headers,--enable-shared=headers,\
--enable-module=imap,--enable-shared=imap,\
--enable-module=include,--enable-shared=include,\
--enable-module=info,--enable-shared=info,\
--enable-module=log_agent,--enable-shared=log_agent,\
--enable-module=log_config,--enable-shared=log_config,\
--enable-module=log_referer,--enable-shared=log_referer,\
--enable-module=mime,--enable-shared=mime,\
--enable-module=mime_magic,--enable-shared=mime_magic,\
--enable-module=mmap_static,--enable-shared=mmap_static,\
--enable-module=negotiation,--enable-shared=negotiation,\
--enable-module=proxy,--enable-shared=proxy,\
--enable-module=rewrite,--enable-shared=rewrite,\
--enable-module=setenvif,--enable-shared=setenvif,\
--enable-module=speling,--enable-shared=speling,\
--enable-module=status,--enable-shared=status,\
--enable-module=unique_id,--enable-shared=unique_id,\
--enable-module=userdir,--enable-shared=userdir,\
name space problem
Okay, So I may be a fool for asking this question, but I hope you will all forgive me. I am fairly new to Perl and really really new to mod_perl. I am working to convert my site to use mod_perl and am having problems with two require statements that exist in most of my scripts. Basically, the require statements point to two other scripts that are back end handler scripts. They are comprised of a couple of subroutines each. Everything works great if I don't run the site through mod_perl as you can imagine. When I do run the site through mod_perl I get internal server errors reported from apache. The errors in the error_log report: ModPerl::Registry: Undefined subroutine ModPerl::ROOT::ModPerl::Registry::var_www_test_home::doSession called at /var/www/test/home line 48. The line in the home script is: my ($user_id,$session_key) = doSession ($page_number,$command,$secure,$page_name); with the require line reading: require /var/www/test/session_key.pl; I'm still reading the numerous web sites that refer to this problem, am hoping to find a quick fix/good explanation of this problem. Thank you, Eric
Re: the perl Script called from perlTranshandler seems to be synchronized
Hello All, I am having a peculiar problem it seems that only one request can be serviced at a time while using mod_perl (perlTransHandler). we are using Apache 1.3.26 mod_perl It seems as though when I use mod_perl apache can handle only one request at a time. If the first request takes say 10 minutes to get response, during this 10 minutes all other requests are blocked, and are handled only after the first request is successfully processed and response sent out This is very important for us to decide if we want to use mod_perl. please advise. Your help will be much appreciated. regards Harsha Yale -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: the perl Script called from perlTranshandler seems to besynchronized
On Wed, 22 Jan 2003, Db-Doc SP wrote: Hello All, I am having a peculiar problem it seems that only one request can be serviced at a time while using mod_perl (perlTransHandler). we are using Apache 1.3.26 mod_perl It seems as though when I use mod_perl apache can handle only one request at a time. If the first request takes say 10 minutes to get response, during this 10 minutes all other requests are blocked, and are handled only after the first request is successfully processed and response sent out Would this happen to be on Win32? If so, you're probably running into the mod_perl 1.0 multithreading issues - see http://perl.apache.org/docs/1.0/os/win32/multithread.html and then http://perl.apache.org/docs/2.0/os/win32/install.html for information on installing mod_perl 2.0 to avoid this problem. -- best regards, randy kobes
Re: name space problem
[EMAIL PROTECTED] wrote: Okay, So I may be a fool for asking this question, but I hope you will all forgive me. I am fairly new to Perl and really really new to mod_perl. I am working to convert my site to use mod_perl and am having problems with two require statements that exist in most of my scripts. Basically, the require statements point to two other scripts that are back end handler scripts. They are comprised of a couple of subroutines each. Everything works great if I don't run the site through mod_perl as you can imagine. When I do run the site through mod_perl I get internal server errors reported from apache. The errors in the error_log report: ModPerl::Registry: Undefined subroutine ModPerl::ROOT::ModPerl::Registry::var_www_test_home::doSession called at /var/www/test/home line 48. The line in the home script is: my ($user_id,$session_key) = doSession ($page_number,$command,$secure,$page_name); with the require line reading: require /var/www/test/session_key.pl; I'm still reading the numerous web sites that refer to this problem, am hoping to find a quick fix/good explanation of this problem. I don't think anybody will call you a fool for asking a question. The worst you can get is the RTFM reply, which follows :) Don't read numerous sites, read the *only* site, perl.apache.org. Because the majority of sites that have mirrored the guide are badly outdated. 1. go perl.apache.org 2. search for Undefined subroutine the 4th and 5th hits give you want you want. since this problem is the same in mod_perl 1.0 and 2.0 the solution should be moved out from the 1.0 guide, into the generic docs. Doc patches are welcome. __ 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
[win32] upgrading to Apache 2.0.44
Sorry for the (slightly) off-topic post, but if you're a Win32 user and are looking to upgrade to Apache 2.0.44 due to some security fixes, some people have reported problems on Win98 with the upgrade. The Apache people have identified the problem, and most likely a fix will be released shortly. -- best regards, randy kobes
stability of apache 2.0 implications on mod_perl?
The announcement of Apache 2.0.44 includes this: The 2.0.44 release marks a change in the Apache release process and a new level of stability in the 2.0 series. Beginning with this release, we will make every effort to retain forward compatibility in the configuration and module API, so that upgrading along the 2.0 series should be much easier. This compatibility extends backwards to 2.0.42, so users of that version or later should be able to upgrade without changing configurations or updating DSO modules. (Users of earlier releases will need to recompile all modules in order to upgrade to 2.0.44.) Does this mean that mod_perl 2.0 can finally be finished? I recall this being dougm's main objection to finishing it all up...
Re: [mp2] Apache::RequestRec, IPC::Open[23] problem
Ville Skyttä wrote:
Hi,
The script below under mod_perl 1.99_08 (ModPerl::Registry), gives me
this:
Can't locate object method FILENO via package
Apache::RequestRec at /usr/lib/perl5/5.8.0/IPC/Open3.pm line 196.
A real world example of a script that has these problems is the W3C
Markup Validator,
http://dev.w3.org/cvsweb/validator/httpd/cgi-bin/check?rev=1.200.2.79.
The validator works under mod_perl 1, and I guess the test script would
as well (I'm unable to verify that at the moment, though). Maybe a
mod_perl 2 bug/missing feature?
My installation is Red Hat 8.0, Apache 2.0.40, mod_perl 1.99_08 and Perl
5.8.0. The test script:
use IPC::Open2 qw(open2);
use IO::File ();
my $in = IO::File-new_tmpfile();
my $out = IO::File-new_tmpfile();
print $in foobar\n;
seek $in, 0, 0;
print Content-Type: text/plain\n\n;
my $pid = open2($out, $in, 'tee');
undef $in;
waitpid $pid, 0;
seek $out, 0, 0;
while ($out) {
print;
}
undef $out;
Please try again with the latest cvs, I've just ported FILENO, OPEN and CLOSE
interfaces from 1.0. Though I doubt that this will work, IPC::Open* have
always had problems with mod_perl. IPC::Run should be used instead for now.
Hopefully will be able to look more into this issue much later unless someone
beats me to it.
__
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: stability of apache 2.0 implications on mod_perl?
Vivek Khera wrote: The announcement of Apache 2.0.44 includes this: The 2.0.44 release marks a change in the Apache release process and a new level of stability in the 2.0 series. Beginning with this release, we will make every effort to retain forward compatibility in the configuration and module API, so that upgrading along the 2.0 series should be much easier. This compatibility extends backwards to 2.0.42, so users of that version or later should be able to upgrade without changing configurations or updating DSO modules. (Users of earlier releases will need to recompile all modules in order to upgrade to 2.0.44.) Does this mean that mod_perl 2.0 can finally be finished? I recall this being dougm's main objection to finishing it all up... We still have to see that this promise will be kept (we will make every effort...). Don't forget that we also rely on the apr project, whose API is not frozen yet. But otherwise it can be finished sooner if we get more people trying to shake out bugs and send patches for features that are still missing. Also helping us to have a more covering test suite would be very helpful. Currently, I believe, we have most of the functionality tested at the very basic level. Covering the odd cases and the whole API is what we need. So read on how to write tests and send in new tests or extend the existing ones. Currently I'm trying to finish the filtering API, which keeps on getting delayed to solve the bug reports. Then I'll go back to work on the other missing things. Philippe has promised to finish the Perl sections, so I think the configuration functionality will be completed soon. If you have a burning need for some missing functionality, speak up. __ 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
