Re: [mp2 ANNOUNCE] Apache-ParseFormData-0.06 (new module)
Thank's for yours comments. You are right, is not a replacement for Apache::Request, is a alternative implementation. On Wed, 30 Jul 2003, Stas Bekman wrote: Henrique Dias wrote: I'm pleased to announce the release of Apache-ParseFormData-0.06, a replace for Apache::Request (libapreq). Cool. Though it's implemented in perl (==slower). Did you try to replicate it because of being frustrated of not having Apache::Request? Would be nice if the interested parties offer help to finish libapreq (on the apreq-dev list). And get_client_block() still has problems in the latest apache 2.0 :( This module only work with mod_perl-2 and apache 2. http://search.cpan.org/author/HDIAS/Apache-ParseFormData-0.06/ParseFormData.pm But I think your doc needs some more work as it says: my $apr = Apache::Request-new($r, disable_uploads = 1); ^^^ or is it on purpose as a drop-in replacement? __ 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 -- Henrique Manuel Ribeiro Dias Escola Superior de Biotecnologia - UCP Gabinete de Desenvolvimento de Software Rua Dr. Antonio Bernardino de Almeida 4200 Porto Portugal Tel: 351-225580092 CPAN: http://www.cpan.org/authors/id/H/HD/HDIAS/
[mp2 ANNOUNCE] Apache-ParseFormData-0.06 (new module)
I'm pleased to announce the release of Apache-ParseFormData-0.06, a replace for Apache::Request (libapreq). This module only work with mod_perl-2 and apache 2. http://search.cpan.org/author/HDIAS/Apache-ParseFormData-0.06/ParseFormData.pm Thanks, Henrique Dias -- Henrique Manuel Ribeiro Dias Escola Superior de Biotecnologia - UCP Gabinete de Desenvolvimento de Software Rua Dr. Antonio Bernardino de Almeida 4200 Porto Portugal Tel: 351-225580092 CPAN: http://www.cpan.org/authors/id/H/HD/HDIAS/
Re: [mp2 ANNOUNCE] Apache-ParseFormData-0.06 (new module)
Henrique Dias wrote: I'm pleased to announce the release of Apache-ParseFormData-0.06, a replace for Apache::Request (libapreq). Cool. Though it's implemented in perl (==slower). Did you try to replicate it because of being frustrated of not having Apache::Request? Would be nice if the interested parties offer help to finish libapreq (on the apreq-dev list). And get_client_block() still has problems in the latest apache 2.0 :( This module only work with mod_perl-2 and apache 2. http://search.cpan.org/author/HDIAS/Apache-ParseFormData-0.06/ParseFormData.pm But I think your doc needs some more work as it says: my $apr = Apache::Request-new($r, disable_uploads = 1); ^^^ or is it on purpose as a drop-in replacement? __ 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
[ANNOUNCE] Apache::App::Mercury (new module)
This is a new application for mod_perl - just released. Apache::App::Mercury is a customizable, extensible customer to customer, store and forward messaging application for Apache mod_perl (1.x). It uses a relational database (accessed via DBI) to store and retrieve messages, and uses CGI.pm to display them in standard HTML. It's design closely resembles a MVC design pattern, and it handles all message box navigation, message composition, sending, replying, etc. In short, it is a complete web (intra server) messaging application for your Apache mod_perl server, which can be customized to fit your specific needs (e.g. private labelling). At the moment, installation has quite a few steps. Sorry about that. I tried to make it as simple and straightforward as possible, but the complexity is necessary since it needs to tie into your existing mod_perl app. Cheers, -Adi -- The URL http://adiraj.org/sw/Apache-App-Mercury/Apache-App-Mercury-0.80.tar.gz has entered CPAN as file: $CPAN/authors/id/A/AD/ADIRAJ/Apache-App-Mercury-0.80.tar.gz size: 38372 bytes md5: 96d5369bf2ad83168ce00829c0102357 No action is required on your part Request entered by: ADIRAJ (Adi Fairbank) Request entered on: Sun, 20 Jul 2003 04:31:15 GMT Request completed: Sun, 20 Jul 2003 04:32:58 GMT
Re: New module : Apache::Session::Manager
On 16 Nov 2002 13:24:13 +0200 Clinton Gormley [EMAIL PROTECTED] wrote: I've written a new module as a wrapper around Apache::Session which provides short term (ie session) tracking (which is something that Apache::SessionManager and Apache::SessionX provide), but this adds long term user tracking, and methods to aid login, logout etc. I would appreciate feedback, not least of all, what it should be called! Apache::SessionManager exists already, and I realise that calling this module Apache::Session::Manager will cause confusion, so please... Dear Clinton, I think that the name you've chosen (Apache::Session::Manager) is wrong :-( not because it will cause confusion with my Apache::SessionManager module, but because Apache::Session::* namespace is informally reserved to Apache::Session sub components like data storage, serializers or ID generators. Your (and my, of course) session manager module hasn't any relationships with these. This name adds only a little bit of confusion on wrong (historically) Apache::Session namespace - there is a direct tie between Apache::Session and mod_perl? ;-) When I started with my little project I've first searched on CPAN and the most similar module I founded was the AxKit-XSP-Session. Unfortunately this is a session manager plugin for AxKit and my goal was to develope a module with no glue with other applications server that the mod_perl itself. Then I've chosen Apache::SessionManager (I've discarded Apache::Session::Manager name, of course) but before putting the first line of code on CPAN, I have sended various RFCs to mod_perl and [EMAIL PROTECTED] mailing lists, to comp.lang.perl.misc and comp.lang.perl.modules: this is the standard way to contribute to CPAN. See ml/news archives for the complete threads [...] I have done a (very) quick look to your code and I've seen some likeness with Apache::AuthCookie and/or Apache-AxKit-Plugin-Session. If you were doing something like this, you could probably start with one of the Auth* modules, which already do a good job of handling things. I am also working to add this features not to my module but adding session management in Apache::AuthCookie! Moreover, I agree about a possibility of the integration with your additional features into my Apache::SessionManager. Regards - Enrico
Re: New module : Apache::Session::Manager
Hi Enrico After posting, I looked at Apache::AuthCookie for the first time - don't why I hadn't looked at it before - to find that I was, indeed, duplicating a lot of work that has been done before. Didn't I feel foolish! It looks like Perrin may have to write a ...why not to write your own session manager article... to compliment his Templating article. Apologies for this. I'll haul my sorry ass back to my machine now. Clint
New module : Apache::Session::Manager
I've written a new module as a wrapper around Apache::Session which provides short term (ie session) tracking (which is something that Apache::SessionManager and Apache::SessionX provide), but this adds long term user tracking, and methods to aid login, logout etc. It is meant to be subclassed, so that you can add your own database access methods to the module - full examples included! I would appreciate feedback, not least of all, what it should be called! Apache::SessionManager exists already, and I realise that calling this module Apache::Session::Manager will cause confusion, so please... README is below. The module is available from : http://cpan.perl.org/modules/by-authors/id/D/DR/DRTECH/Apache-Session-Manager-0.02.tar.gz thanks Clinton Apache/Session/Manager version 0.02 === Apache::Session::Manager provides a wrapper around Apache::Session which adds the following : * Short term session tracking using cookies or URLs (query string / POST data rather than URL munging) * Long term user tracking with cookies and query string * User recognition through query string (eg from an emailed link) * Login, logout, create new account, remove cookies - all operating with your favourite database and schema! It needs to be subclassed by your own module, which provides the methods to interact with your database - ie you can integrate this module into you own database schema. Apache::Session::Manager is not a drop in module - it requires a bit of work on your part to make it work - but once that work is done, it makes a lot of user and session management easy. Any website that wants to have any sort of long term relationship with a user needs to be able to track a user through a session, allow the user to register, and issue them with a password challenge before allowing them to view restricted pages... which is exactly what this module does. All you need to provide is 6 subroutines which speak to your database to perform a few simple functions (looking up a username etc).
Re: RFC: new module: Apache::FakeEnv
Hello, GYthere was a more advanced Apache::FakeRequest floating around somewhere... TKI knew this script (it was posted here, too), and while it is definitly TKbetter than Apache::FakeRequest, it still doesn't handle dir_config TKcalls. That's my script. The caveat is, that it will *never* be possible to simulate mod_perl entirely--that would be so complex that you might as well have everybody run a single-child Apache with mod_perl instead. We do this for our mod_perl developers. There is perl -wc for simple syntax checking, the apr script for running dead-simple mod_perl scripts for debugging, and then everybody runs a small Apache against their own conf file to test stuff. GYany chance you can expand the existing Apache::FakeRequest GYand offer a patch? TKSure I could try to patch Apache::FakeRequest, but I think the TKchanges are quite fundamental. What to the mantainers of TKApache::FakeRequest (or mod_perl) think of this? I agree that the changes are quite fundamental. I haven't really found Apache::FakeRequest terribly useful. It doesn't really make debugging mod_perl handlers any easier by itself. Rather than patching it, perhaps you could subclass it or replace it altogether. TKIs it possible to subclass mod_perl or Apache::Request from TKoutside of Apache (i.e. in a plain perl environment) ? Nope, as you guessed. :( TKIf not (which it seems to be), what would be the best way to TKimplement all (more or less..) mod_perl methods and subclasses TK(Apache::Request et.al) ? Can one use the C code that mod_perl TKis based on? (Well, I guess I can't because I've never done any real TKC coding ...) ? The best way to do it would probably just be to write code for 'em all. I think many web developers have many of the pieces lying around anyway from web client libraries. The hard work is in faking out everything and matching the API. But then you run into the problem that the code you're making isn't really mod_perl and Apache anyway. I'd say that having something pretty good for doing fast testing of mod_perl scripts is good, but you'll never be 100% mod_perl unless you're using mod_perl itself. :) 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: RFC: new module: Apache::FakeEnv
Hi! Geoffrey Young: there was a more advanced Apache::FakeRequest floating around somewhere... I think this was it, but I swore it was something on the dev@ list: http://marc.theaimsgroup.com/?l=apache- modperlm=98719810927157w=2 I knew this script (it was posted here, too), and while it is definitly better than Apache::FakeRequest, it still doesn't handle dir_config calls. Geoffrey Young: generally, I would think that feature enhancements to Apache::FakeRequest would be preferred over another module that is essentially the same - a better FakeRequest has been on the ToDo list for some time now... any chance you can expand the existing Apache::FakeRequest and offer a patch? Sure I could try to patch Apache::FakeRequest, but I think the changes are quite fundamental. What to the mantainers of Apache::FakeRequest (or mod_perl) think of this? darren chamberlain: Don't know about the rest, but I saw Config::General, which will parse an Apache config file into a hash. Very useful, and very well done. I took a look at this module, and while it parses simple Apache config files correctly, it won't work with more complex ones. For example, it doesn't handle Include directivec (altough I submitted a patch to the author, so it will work with Apache Includes) and it can't parse VirtualHost Sections correctly. This questions of my initial posting are still unanswered: * Is it possible to subclass mod_perl or Apache::Request from outside of Apache (i.e. in a plain perl environment) ? * If not (which it seems to be), what would be the best way to implement all (more or less..) mod_perl methods and subclasses (Apache::Request et.al) ? Can one use the C code that mod_perl is based on? (Well, I guess I can't because I've never done any real C coding ...) ? -- D_omm O_xyderkes http://domm.zsi.at M_echanen M_asteuei
RFC: new module: Apache::FakeEnv
Hi! I am currently working on a module that generates a Fake Apache Request Object like Apache::FakeRequest does, but that also parses the Apache Configuration and enables the user to access values set with PerlSetVar (i.e. fake $r-dir_config). This Request Object can than be used in mod_perl modules, when running from the command line. I have a first (sort of) working version at: http://domm.zsi.at/source_code/Apache-FakeEnv.pm and the documentation at: http://domm.zsi.at/Apache-FakeEnv.html or embedded in Apache-FakeEnv.pm in pod-format This module has some limitations (see Section Limitations in the doc) that I would like to remove, but I'm not sure how, so ... * Is it possible to subclass mod_perl or Apache::Request from outside of Apache (i.e. in a plain perl environment) ? * If not (which it seems to be), what would be the best way to implement all (more or less..) mod_perl methods and subclasses (Apache::Request et.al) ? Can one use the C code that mod_perl is based on? (Well, I guess I can't because I've never done any real C coding ...) ? * Does a parser for the Apache Conifg Files exist somewhere (Parse::ReDescent or similar) or can one use the Apache Source Code or Apache itself to parse the config ? * Do you think that this module could be of interest to others (Should I put it on CPAN) ? Thanks for your attention ! -- D_omm O_xyderkes http://domm.zsi.at M_echanen M_asteuei
RE: new module: Apache::FakeEnv
-Original Message- From: Thomas Klausner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 20, 2001 11:27 AM To: modperl Subject: RFC: new module: Apache::FakeEnv Hi! I am currently working on a module that generates a Fake Apache Request Object like Apache::FakeRequest does, but that also parses the Apache Configuration and enables the user to access values set with PerlSetVar (i.e. fake $r-dir_config). there was a more advanced Apache::FakeRequest floating around somewhere... I think this was it, but I swore it was something on the dev@ list: http://marc.theaimsgroup.com/?l=apache-modperlm=98719810927157w=2 [snip] * Do you think that this module could be of interest to others (Should I put it on CPAN) ? Thanks for your attention ! generally, I would think that feature enhancements to Apache::FakeRequest would be preferred over another module that is essentially the same - a better FakeRequest has been on the ToDo list for some time now... any chance you can expand the existing Apache::FakeRequest and offer a patch? my $0.02 --Geoff
Re: RFC: new module: Apache::FakeEnv
Thomas Klausner ([EMAIL PROTECTED]) said something to this effect on 06/20/2001: Hi! I am currently working on a module that generates a Fake Apache Request Object like Apache::FakeRequest does, but that also parses the Apache Configuration and enables the user to access values set with PerlSetVar (i.e. fake $r-dir_config). *snip* * Does a parser for the Apache Conifg Files exist somewhere (Parse::ReDescent or similar) or can one use the Apache Source Code or Apache itself to parse the config ? Don't know about the rest, but I saw Config::General, which will parse an Apache config file into a hash. Very useful, and very well done. (darren) -- It is impossible to experience one's death objectively and still carry a tune. -- Woody Allen
new module: mod_raah (Apache API via Corba)
I've stumbled upon mod_raah while reading http://simplex.ru/news/koi/ (sorry it's in koi charset :). It was referencing to http://www.opencentrix.com/opensource/mod_raah/ This is what is has to say: Mod_Raah exposes a subset of the Apache API via Corba. It allows a programmer to write Apache handlers that run on a remote machine. The three phases Authentication, Authorization and Content are supported. and there is a nice diagram depicting the functionality... So in case you are looking for an opportunity to write a new Apache:: module, it seems that Apache::RAAH is still an open vacancy :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: New Module Idea: MLDBM::Sync
Tim Bunce wrote: I looked through the code and couldn't see how you are doing i/o flushing. This is more of an issue with Berkeley DB than SDBM I think, since Berkeley DB will cache things in memory. Can you point to me it? I'm puzzled why people wouldn't just use version 3 of Berkeley DB (via DB_File.pm or BerkeleyDB.pm) which supports multiple readers and writers through a shared memory cache. No open/close/flush required per-write and very very much faster. Is there a reason I'm missing? I'm not sure I want to go the shared memory route, generally, and if I were to, I'd likely start with like you say BerkeleyDB or IPC::Cache. I know there isn't much of a learning curve, but its not complexity that I want to add to the system I'm working on now. I've been doing stuff like MLDBM::Sync for a while making DBMs work in multiprocess environment, and its comforting. 1000 reads/writes per second is enough for my caching needs now, as its just a front end to SQL queries. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
Paul Lindner wrote: I'm puzzled why people wouldn't just use version 3 of Berkeley DB (via DB_File.pm or BerkeleyDB.pm) which supports multiple readers and writers through a shared memory cache. No open/close/flush required per-write and very very much faster. Is there a reason I'm missing? Might MLDBM::Sync work over an NFS mounted partition? That's one reason I've not used the BerkeleyDB stuff yet.. Kinda, but only in SDBM_File mode like Apache::ASP state. Kinda, because flock() doesn't work over NFS, and that other patch we worked with that called NFS locking didn't work when I load tested it. I've heard that a samba share might support file locking transparently, but have yet to test this. MLDBM::Sync uses a similar method that Apache::ASP::State does to keep data synced. In an NFS environment, whether data gets committed is a matter of chance of collision. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use Sambe, not NFS [Re: New Module Idea: MLDBM::Sync]
Paul Lindner wrote: Might MLDBM::Sync work over an NFS mounted partition? That's one reason I've not used the BerkeleyDB stuff yet.. Paul, For the first time, I benchmarked concurrent linux client write access over a SAMBA network share, and it worked, 0 data loss. This is opposed to a NFS share accessed from linux which would see data loss due to lack of serialization of write requests. With MLDBM::Sync, I benchmarked 8 linux clients writing to a samba mount pointed at a WinNT PIII 450 over a 10Mbs network. For 8000 writes, I got: SDBM_File: 105 writes/sec DB_File:99 writes/sec [ better than to local disk ] It seems the network was the bottleneck on this test, as neither client nor server CPU/disk was maxed out. The WinNT server was running at 20-25% CPU utilization during the test. As Apache::ASP $Session uses a method similar to MLDBM::Sync to flush i/o, you could then point StateDir to a samba/CIFS share to cluster well an ASP application, with 0 data loss. My understanding is that you have a NetApp cluster which can export CIFS? I'd benchmark this heavily obviously to see if there are any NetApp cluster locking issues, but am guessing that you could likely get 200+ ASP requests per second on a 100Mbs network, which will likely far exceed your base application performance. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
On Wed, Nov 22, 2000 at 10:58:43AM +, Tim Bunce wrote: On Tue, Nov 21, 2000 at 03:00:01PM -0800, Perrin Harkins wrote: On Fri, 17 Nov 2000, Joshua Chamas wrote: I'm working on a new module to be used for mod_perl style caching. I'm calling it MLDBM::Sync because its a subclass of MLDBM that makes sure concurrent access is serialized with flock() and i/o flushing between reads and writes. I looked through the code and couldn't see how you are doing i/o flushing. This is more of an issue with Berkeley DB than SDBM I think, since Berkeley DB will cache things in memory. Can you point to me it? I'm puzzled why people wouldn't just use version 3 of Berkeley DB (via DB_File.pm or BerkeleyDB.pm) which supports multiple readers and writers through a shared memory cache. No open/close/flush required per-write and very very much faster. Is there a reason I'm missing? Might MLDBM::Sync work over an NFS mounted partition? That's one reason I've not used the BerkeleyDB stuff yet.. -- Paul Lindner [EMAIL PROTECTED] Red Hat Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
On Wed, 22 Nov 2000, Tim Bunce wrote: I'm puzzled why people wouldn't just use version 3 of Berkeley DB (via DB_File.pm or BerkeleyDB.pm) which supports multiple readers and writers through a shared memory cache. No open/close/flush required per-write and very very much faster. Is there a reason I'm missing? There are a few. It's much harder to build than most CPAN modules, partly because of conflicts some people run into with the db library Red Hat provides. The documentation is pretty weak on how to use it with a shared memory environment. (You have to use BerkeleyDB.pm for this incidentally; DB_File does not support it.) We got past these problems and then ran into issues with db corruption. If Apache gets shut down with a SIGKILL (and this seems to happen fairly often when using mod_perl), the data can be corrupted in such a way that when you next try to open it BerkeleyDB will just hang forever. Sleepycat says this is a known issue with using BerkeleyDB from Apache and they don't have a solution for it yet. Even using their transaction mechanism does not prevent this problem. We tried lots of different things and finally have reached what seems to be a solution by using database-level locks rather than page-level. We still get to open the database in ChildInit and keep it open, with all the speed benefits of the shared memory buffer. It is definitely the fastest available way to share data between processes, but the problems we had have got me looking at other solutions again. If you do try it out, I'd be eager to hear what your experiences with it are. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
On Wed, Nov 22, 2000 at 02:17:25PM +0300, Ruslan V. Sulakov wrote: Hi, Tim! I'd like to use BerkeleyDB! But have you test it in mod_perl environment? Not yet, but I will be very soon. I'm sure others are using it. May be I wrote scripts in wrong fasion. I open $dbe and $db at startup.pl of mod_perl Why do you think that no open/close/flush required? Not required *per write*. Open when the child is started and close when the child exits. (Probably best not to open in the parent. I haven't checked the docs yet.) No flush needed as the cache is shared and the last process to disconnect from it will flush it automatically. Each new apache server generation (about 1 time per 30 request in my case) need to run starup.pl So, how to syncronize changes between different apache server processes when no flush made? Or am I not write? Or synchronization between simaltanious BerkeleyDB objects is done automatically throwgh DBEnvironment? I believe so. I think ,this theme is very important to all developers! Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
On Fri, 17 Nov 2000, Joshua Chamas wrote:
I'm working on a new module to be used for mod_perl style
caching. I'm calling it MLDBM::Sync because its a subclass
of MLDBM that makes sure concurrent access is serialized with
flock() and i/o flushing between reads and writes.
I looked through the code and couldn't see how you are doing i/o
flushing. This is more of an issue with Berkeley DB than SDBM I think,
since Berkeley DB will cache things in memory. Can you point to me it?
Also, I'm confused on the usage. Do you open the dbm file and keep it
open, or do you tie/untie on every request?
Any thoughts?
You might want to look at the Mason caching API. It would be nice to make
an interface like that available on top of a module like this.
- Perrin
package MLDBM::Sync;
use MLDBM;
use Fcntl qw(:flock);
use strict;
no strict qw(refs);
use vars qw($AUTOLOAD);
sub TIEHASH {
my($class, $file, @args) = @_;
my $fh = "$file.lock";
open($fh, "$fh") || die("can't open file $fh: $!");
bless {
'args' = [ $file, @args ],
'lock' = $fh,
'keys' = [],
};
}
sub DESTROY {
my $self = shift;
if (($self-{lock})) {
close($self-{lock})
}
}
sub AUTOLOAD {
my $self = shift;
$AUTOLOAD =~ /::([^:]+)$/;
my $func = $1;
$self-exlock;
my $rv = $self-{dbm}-$func(@_);
$self-unlock;
$rv;
}
sub STORE {
my $self = shift;
$self-exlock;
my $rv = $self-{dbm}-STORE(@_);
$self-unlock;
$rv;
};
sub FETCH {
my $self = shift;
$self-shlock;
my $rv = $self-{dbm}-FETCH(@_);
$self-unlock;
$rv;
};
sub FIRSTKEY {
my $self = shift;
$self-shlock;
$self-{keys} = [ keys %{$self-{dbm_hash}} ];
$self-unlock;
$self-NEXTKEY;
}
sub NEXTKEY {
shift(@{shift-{keys}});
}
sub mldbm_tie {
my $self = shift;
my $args = $self-{args};
my %dbm_hash;
my $dbm = tie(%dbm_hash, 'MLDBM', @$args) || die("can't tie to MLDBM with args:
".join(',', @$args)."; error: $!");
$self-{dbm_hash} = \%dbm_hash;
$self-{dbm} = $dbm;
}
sub exlock {
my $self = shift;
flock($self-{lock}, LOCK_EX) || die("can't write lock $self-{lock}: $!");
$self-mldbm_tie;
}
sub shlock {
my $self = shift;
flock($self-{lock}, LOCK_SH) || die("can't share lock $self-{lock}: $!");
$self-mldbm_tie;
}
sub unlock {
my $self = shift;
undef $self-{dbm};
untie %{$self-{dbm_hash}};
flock($self-{lock}, LOCK_UN) || die("can't unlock $self-{lock}: $!");
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
Perrin Harkins wrote: On Fri, 17 Nov 2000, Joshua Chamas wrote: I'm working on a new module to be used for mod_perl style caching. I'm calling it MLDBM::Sync because its a subclass of MLDBM that makes sure concurrent access is serialized with flock() and i/o flushing between reads and writes. I looked through the code and couldn't see how you are doing i/o flushing. This is more of an issue with Berkeley DB than SDBM I think, since Berkeley DB will cache things in memory. Can you point to me it? Also, I'm confused on the usage. Do you open the dbm file and keep it open, or do you tie/untie on every request? Yes, tie/untie every request as this consistently flushes i/o in an atomic way for SDBM_File, DB_File, GDBM_File... Without this data can be lost, even for SDBM_File, if multiple processes have tied to these DBMs and are writing concurrently. SDBM_File doesn't get corrupt though like DB_File, so access to it would seem error free without this sync method. On my box, some rough numbers in writes per sec, with doing a tie/untie for each write, are: sync writes/sec with tie/untie SDBM_File 1000 DB_File 30 GDBM_File 40 Note that on a RAM disk in Linux, DB_File goes to 500 writes per sec, but setting up a RAM disk is a pain, so I'd probably use File::Cache which gets about 300 writes per sec on the file system. You might want to look at the Mason caching API. It would be nice to make an interface like that available on top of a module like this. Because of the 1024 byte SDBM_File limit, Mason would probably be better off using File::Cache for caching, but for little bits of data SDBM_File with MLDBM::Sync works really well. Thanks for the feedback. BTW, if you want to experiment with it, the module code I posted will only provide SDBM_File access. I have a fixed version which will work for any DBM format that MLDBM works with, so let me know and I'll send you my latest. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Module Idea: MLDBM::Sync
On Tue, 21 Nov 2000, Joshua Chamas wrote: On my box, some rough numbers in writes per sec, with doing a tie/untie for each write, are: sync writes/sec with tie/untie SDBM_File 1000 DB_File 30 GDBM_File 40 Note that on a RAM disk in Linux, DB_File goes to 500 writes per sec, but setting up a RAM disk is a pain, so I'd probably use File::Cache which gets about 300 writes per sec on the file system. Useful numbers. It looks as if File::Cache is the best approach if you need anything beyond the SDBM size limit. Maybe some fine-tuning of that module could bring it more in line with SDBM performance. If you have the RAM to spare - and I guess you do, if you're considering things like RAM disks - you could try IPC::MM too. I think it will be faster than the other IPC modules because it's a Perl API to a shared hash written in C. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Module Idea: MLDBM::Sync
Hey,
I'm working on a new module to be used for mod_perl style
caching. I'm calling it MLDBM::Sync because its a subclass
of MLDBM that makes sure concurrent access is serialized with
flock() and i/o flushing between reads and writes. Below is
the code for the module. I believe it could be used too as a
safe backing store for Memoize in a multi-process environment.
It could be used like:
tie %mldbm, 'MLDBM::Sync', '/tmp/mldbm_dbm', O_CREAT|O_RDWR, 0666;
$mldbm{rand()} = [ rand() ];
%mldbm = ();
The history is that I hunted around for on disk caching in
which I can stuff db query results temporarily, and the best I
liked was File::Cache, which is really cool BTW. I would use it,
but MLDBM::Sync using default SDBM_File seems to be 2 to 3 times
faster, getting about 1000 writes / sec on my dual PIII 400.
MLDBM::Sync using MLDBM in DB_File mode is considerably slower
than File::Cache, by 5-10 times, so it really depends on the
data you want to store, for which you might use. The 1024 byte
limit on SDBM_File makes it often not the right choice.
I also thought about calling it MLDBM::Lock, MLDBM::Serialize,
MLDBM::Multi ... I like MLDBM::Sync though. For modperl
caching usage, I imagine tieing to it in each child, and clearing
when necessary, perhaps even at parent httpd initialization...
no auto-expiration here, use File::Cache, IPC::Cache for that!
Any thoughts?
--Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
package MLDBM::Sync;
use MLDBM;
use Fcntl qw(:flock);
use strict;
no strict qw(refs);
use vars qw($AUTOLOAD);
sub TIEHASH {
my($class, $file, @args) = @_;
my $fh = "$file.lock";
open($fh, "$fh") || die("can't open file $fh: $!");
bless {
'args' = [ $file, @args ],
'lock' = $fh,
'keys' = [],
};
}
sub DESTROY {
my $self = shift;
if (($self-{lock})) {
close($self-{lock})
}
}
sub AUTOLOAD {
my $self = shift;
$AUTOLOAD =~ /::([^:]+)$/;
my $func = $1;
$self-exlock;
my $rv = $self-{dbm}-$func(@_);
$self-unlock;
$rv;
}
sub STORE {
my $self = shift;
$self-exlock;
my $rv = $self-{dbm}-STORE(@_);
$self-unlock;
$rv;
};
sub FETCH {
my $self = shift;
$self-shlock;
my $rv = $self-{dbm}-FETCH(@_);
$self-unlock;
$rv;
};
sub FIRSTKEY {
my $self = shift;
$self-shlock;
$self-{keys} = [ keys %{$self-{dbm_hash}} ];
$self-unlock;
$self-NEXTKEY;
}
sub NEXTKEY {
shift(@{shift-{keys}});
}
sub mldbm_tie {
my $self = shift;
my $args = $self-{args};
my %dbm_hash;
my $dbm = tie(%dbm_hash, 'MLDBM', @$args) || die("can't tie to MLDBM with args:
".join(',', @$args)."; error: $!");
$self-{dbm_hash} = \%dbm_hash;
$self-{dbm} = $dbm;
}
sub exlock {
my $self = shift;
flock($self-{lock}, LOCK_EX) || die("can't write lock $self-{lock}: $!");
$self-mldbm_tie;
}
sub shlock {
my $self = shift;
flock($self-{lock}, LOCK_SH) || die("can't share lock $self-{lock}: $!");
$self-mldbm_tie;
}
sub unlock {
my $self = shift;
undef $self-{dbm};
untie %{$self-{dbm_hash}};
flock($self-{lock}, LOCK_UN) || die("can't unlock $self-{lock}: $!");
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
new module
Hi!
I am currently developing a perl module that is somewhat simmilar
to CGI::PathInfo, and somewhat not. (IMO more not).
The module would be used in a CGI- or mod_perl-environment. It
takes the path-info (or the whole URL) and performs some regular
expressions (defined via some configuration) on it. If the regular
expressions match, the value will be added to $q-param
Example:
URI: /somewhere/on/server/o_date/id1234.html
%config={
order_by='o_(\w+)' ,
id='id(\d+)' ,
};
# code (simplified !!)
while(my($key,$regex)=each(%config)) {
if ($pathinfo=~/$regex/) {
$q-param($key,$+);
}
}
after this code, $q-param('id') holds "1234" and
$q-param('order_by') holds "date"
Do you think this module would be useful for others?
If so, I will try to put in on CPAN.
I am thinking of naming the module CGI::PathInfoRegex or
Apache::PathInfoRegex. Which name is better suited (or should I
choose a totally difrent name?)
The whole module (definitly alpha code) can be found at :
http://domm.zsi.at/PathInfoRegex-0.01.tar.gz
--
D_OMM http://domm.zsi.at
O_xyderkes
M_echanenNEU (naja): Wohnungs-Historie
M_asteuei http://domm.zsi.at/curvit/wohnen.html
Re: [ RFC ] New Module Apache::SessionManager
Matt Sergeant wrote: On Wed, 25 Oct 2000, Gerald Richter wrote: I have three anonations: 1.) $r-header_out(Location = $r-uri()); Also this code works with most browsers it doesn't conform to the HTTP specs. A location header must include a host part. Shouldn't be to hard add something like $r-header_out(Location = 'http://' . $r - server - server_hostname . $r-uri()); + port too. Ok I've not had a chance to play with anything as I recovering from a rather long week On another note I've had little success with Sourceforge - I've set a project up but cannot seem to login to FTP nor upload a CVS snapshot, nor add a description . I've been in touch with support and am awaiting more news. Hence is it worth a CPAN entry ? (I've not got an account ) Anyway thanks for the tips. Greg -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: [ RFC ] New Module Apache::SessionManager
darren chamberlain wrote: Greg Cope ([EMAIL PROTECTED]) said something to this effect: $r-header_out(Location = 'http://' . $r - server - server_hostname . $r-uri()); Seems easy - will add it in. It's not that simple, of course -- you need to maintain port numbers and all that. I recommend using Apache::URI -- create a new Apache::URI object, set its attributes from the Apache object, and then call unparse on it. I don't see the complication - this appears to work ok: my $uri = Apache::URI-parse($r); # hostinfo give port if necessary - otherwise not my $hostinfo = $uri-hostinfo; my $scheme = $uri-scheme . '://'; $redirect = $scheme . $hostinfo . '/'. $session_id . '/' . $rest . $args; This should always give the following redirect URI: http://www.foo.com/456456456456456/orginal_request.hmtl the scheme and port changing as neccessary. The only possible issue is if the hostname / scheme containt duff (un uencoded) chars - which appears illogical to me. Greg (darren) -- In the fight between you and the world, back the world.
Re: [ RFC ] New Module Apache::SessionManager
Gerald Richter wrote: Hi Greg, I also hot heard anything back from the poeple I sent a copy to, I can hence only assume that its so good that it's made them speachless ;-) That's more a matter of time, then a matter of speach... I am up against a deadline and hence will be a little short - but this is excellent. Greg, I have taken a look at your module and the code and I think it is really worth publishing it. I have three anonations: 1.) $r-header_out(Location = $r-uri()); Also this code works with most browsers it doesn't conform to the HTTP specs. A location header must include a host part. Shouldn't be to hard add something like $r-header_out(Location = 'http://' . $r - server - server_hostname . $r-uri()); Seems easy - will add it in. 2.) You use global variables for configuration. While this is fast and easy your aren't be able to have different configurations for different directories or virtual hosts. From my point of view this is a must! I want to only run SessionManager for certain directories and are able to use different configurations for different applications. I would highly recomend to use PerlSetVar for configuration. Ok - will require some changes - will add these. 3.) You have a hard coded make_session_id function. This function should be customable i.e. calling a user defined function which returns a new session id and there should be some way to interact with Apache::Session which already have a (configurable) class that generates session ids. Before the session id is send out to the browser, there must be some way to check if it is valid i.e. doesn't already exists, because it can't be (easily) corrected afterwards. I had orgininally though of this, and decided against as this was simpler. My orgininal thoughts were to: a) keep it very small (the whole thing = fast) b) Keep it very simple The logic is that this module just gets the session ID and other handlers / modules authenticate that session ID. If it is wrong then you need to either change the cookie or redirect to a different ID (if no cookies are set). I can see that adding a call back to a user defined subroutine that returns a Session ID would be possible. Adding in a link to Apache::Session would also be possible. As I wrote above I am up against a deadline and will not be able to do anything till next week - I will impliment the above in the order they are writen as they are in simplest - complex ity order. Thanks Gerald for the feedback above - much appreciated (even if there are quite a few good ideas that involve changes !) Thanks again Greg Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: [ RFC ] New Module Apache::SessionManager
Greg Cope ([EMAIL PROTECTED]) said something to this effect: $r-header_out(Location = 'http://' . $r - server - server_hostname . $r-uri()); Seems easy - will add it in. It's not that simple, of course -- you need to maintain port numbers and all that. I recommend using Apache::URI -- create a new Apache::URI object, set its attributes from the Apache object, and then call unparse on it. (darren) -- In the fight between you and the world, back the world.
Re: [ RFC ] New Module Apache::SessionManager
Hi Greg, I also hot heard anything back from the poeple I sent a copy to, I can hence only assume that its so good that it's made them speachless ;-) That's more a matter of time, then a matter of speach... Greg, I have taken a look at your module and the code and I think it is really worth publishing it. I have three anonations: 1.) $r-header_out(Location = $r-uri()); Also this code works with most browsers it doesn't conform to the HTTP specs. A location header must include a host part. Shouldn't be to hard add something like $r-header_out(Location = 'http://' . $r - server - server_hostname . $r-uri()); 2.) You use global variables for configuration. While this is fast and easy your aren't be able to have different configurations for different directories or virtual hosts. From my point of view this is a must! I want to only run SessionManager for certain directories and are able to use different configurations for different applications. I would highly recomend to use PerlSetVar for configuration. 3.) You have a hard coded make_session_id function. This function should be customable i.e. calling a user defined function which returns a new session id and there should be some way to interact with Apache::Session which already have a (configurable) class that generates session ids. Before the session id is send out to the browser, there must be some way to check if it is valid i.e. doesn't already exists, because it can't be (easily) corrected afterwards. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: [ RFC ] New Module Apache::SessionManager
Gunther Birznieks wrote: I believe Greg is familiar with Apache::Session. There have been discussions about this before. A session manager manages the workflow around sessions. A session stores information. They are two different things. In addition, I believe the name session manager has come up on this list before with regards to this. That just about covers it. Thanks Gunther As for cpan, I have an aliase for th cpan shell, and excellent module. Greg Later, Gunther At 07:04 PM 10/21/00 -0500, James G Smith wrote: Check out Apache::Session, available on CPAN and see if your code could be moulded to fit it's way of thinking. If they are too much different, then you might want to consider contacting the module list to see if what you have is a good name (it probably is) before going all out with distribution (and consider CPAN). For more information, http://www.cpan.org/modules/00modlist.long.html#Part1-Modules:C Greg Cope [EMAIL PROTECTED] wrote: Greg Cope wrote: Dear ALL I've writen a module that does transparent session management via either Cookies, Munged URI or Query Args. It has quite a few options to change the behavour, and appears stable in my developement environment. What I suggest is that unless there is a major objection I call it Apache::SessionManager and set up a Source Forge project with the same name. Unless there is a major issue I assume that by the weekend everyone whom wants to will have made thier view clear and will hopefully go forward from there. Regards Greg Dear All Not having heard anything bad about this I will go ahead a setup a sourceforge project. I also hot heard anything back from the poeple I sent a copy to, I can hence only assume that its so good that it's made them speachless ;-) Seriously, could poeple drop me a note as to how they found it ? I do not want to go to all the trouble of writing docs / install files / source forge projects etc ... if its a load of rubbish and I am wasteing my time. Regards Greg Cope -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: [ RFC ] New Module Apache::SessionManager
Greg Cope wrote: Dear ALL I've writen a module that does transparent session management via either Cookies, Munged URI or Query Args. It has quite a few options to change the behavour, and appears stable in my developement environment. What I suggest is that unless there is a major objection I call it Apache::SessionManager and set up a Source Forge project with the same name. Unless there is a major issue I assume that by the weekend everyone whom wants to will have made thier view clear and will hopefully go forward from there. Regards Greg Dear All Not having heard anything bad about this I will go ahead a setup a sourceforge project. I also hot heard anything back from the poeple I sent a copy to, I can hence only assume that its so good that it's made them speachless ;-) Seriously, could poeple drop me a note as to how they found it ? I do not want to go to all the trouble of writing docs / install files / source forge projects etc ... if its a load of rubbish and I am wasteing my time. Regards Greg Cope
Re: [ RFC ] New Module Apache::SessionManager
Check out Apache::Session, available on CPAN and see if your code could be moulded to fit it's way of thinking. If they are too much different, then you might want to consider contacting the module list to see if what you have is a good name (it probably is) before going all out with distribution (and consider CPAN). For more information, http://www.cpan.org/modules/00modlist.long.html#Part1-Modules:C Greg Cope [EMAIL PROTECTED] wrote: Greg Cope wrote: Dear ALL I've writen a module that does transparent session management via either Cookies, Munged URI or Query Args. It has quite a few options to change the behavour, and appears stable in my developement environment. What I suggest is that unless there is a major objection I call it Apache::SessionManager and set up a Source Forge project with the same name. Unless there is a major issue I assume that by the weekend everyone whom wants to will have made thier view clear and will hopefully go forward from there. Regards Greg Dear All Not having heard anything bad about this I will go ahead a setup a sourceforge project. I also hot heard anything back from the poeple I sent a copy to, I can hence only assume that its so good that it's made them speachless ;-) Seriously, could poeple drop me a note as to how they found it ? I do not want to go to all the trouble of writing docs / install files / source forge projects etc ... if its a load of rubbish and I am wasteing my time. Regards Greg Cope -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
[ RFC ] New Module Apache::SessionManager
Dear ALL I've writen a module that does transparent session management via either Cookies, Munged URI or Query Args. It has quite a few options to change the behavour, and appears stable in my developement environment. What I suggest is that unless there is a major objection I call it Apache::SessionManager and set up a Source Forge project with the same name. Unless there is a major issue I assume that by the weekend everyone whom wants to will have made thier view clear and will hopefully go forward from there. Regards Greg
Re: [ RFC ] New Module Apache::SessionManager
I like the name as it works well with our naming (SessionManager, Session hierarchy) so I can probably write a wrapper that assumes your SessionManager is embedded in Apache and it's not confusing for our users who want to configure our apps to use your session manager. Thanks, Gunther At 06:33 PM 10/17/2000 +, Greg Cope wrote: Dear ALL I've writen a module that does transparent session management via either Cookies, Munged URI or Query Args. It has quite a few options to change the behavour, and appears stable in my developement environment. What I suggest is that unless there is a major objection I call it Apache::SessionManager and set up a Source Forge project with the same name. Unless there is a major issue I assume that by the weekend everyone whom wants to will have made thier view clear and will hopefully go forward from there. Regards Greg __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
[ANNOUNCE] new module HTTPD::Bench::ApacheBench
Stas Bekman wrote: Before I upload it to CPAN, are there any objections to calling it "ApacheBench"? Other names I considered are "Bench", "ab", "ABuse"... but ApacheBench I thought was the best because an m/Apache/ search on CPAN will find it. That's the proper name, since it's a glue code for ab, plus extra fuctionality. The only thing I'd add is a prefix so we could put other Benchmarking implementation under the same tree. Especially as you have mentioned in the pod it's not mod_perl specific. I'd go for HTTPD::Bench:: or HTTPDBench:: tree. Ok, I've renamed it to HTTPD::Bench::ApacheBench. But you have already released it on CPAN, so I don't know... (I couldn't reply earlier since I was preaching mod_perl at YAPC::Europe, which was a very cool conference :) It did go into CPAN but the metadata never got in, so it didn't show up on searches. I hope the rename doesn't affect anyone. Hope you had fun at the conference. I'll make it to one (one of these years). :) Stas, hopefully I'll be able to integrate this with your new Apache::Benchmark module. I haven't had time to look over yours fully, but I'm thinking your module will be a layer around this. Currently Apache::Benchmark uses ab, right? This module almost completely replaces ab. There are a few features that still need to be added. Yup, cool. In fact you are welcome to take over it :) Apache::Benchmark shouldn't be depenfing on the actual engine used for Benchmarking. One should be able to plug any engine instead of ab. Yes, I'll be looking at it extensively in the next few months. So I might just take it over. :) -- The uploaded file ApacheBench-0.51.tar.gz has entered CPAN as file: $CPAN/authors/id/A/AD/ADIRAJ/ApacheBench-0.51.tar.gz size: 46603 bytes md5: d9e5bd55500da2c040fe88c4a08b69ae No action is required on your part Request entered by: ADIRAJ (Adi Fairbank) Request entered on: Tue, 26 Sep 2000 16:18:49 GMT Request completed: Tue, 26 Sep 2000 16:19:31 GMT Virtually Yours, Id: paused,v 1.68 1999/10/22 14:39:12 k Exp k
Re: [ANNOUNCE] new module ApacheBench
On Thu, 21 Sep 2000, Adi wrote:
It took a little longer than planned, but here it is. It is a Perl API to
the Apache ab tool. It took so long because we added a number of useful
features, mainly the ability to benchmark sequences of URLs instead of just
one.
Very nice Adi!
Before I upload it to CPAN, are there any objections to calling it
"ApacheBench"? Other names I considered are "Bench", "ab", "ABuse"... but
ApacheBench I thought was the best because an m/Apache/ search on CPAN will find
it.
That's the proper name, since it's a glue code for ab, plus extra
fuctionality. The only thing I'd add is a prefix so we could put other
Benchmarking implementation under the same tree. Especially as you have
mentioned in the pod it's not mod_perl specific. I'd go for
HTTPD::Bench:: or HTTPDBench:: tree.
But you have already released it on CPAN, so I don't know... (I couldn't
reply earlier since I was preaching mod_perl at YAPC::Europe, which was
a very cool conference :)
Stas, hopefully I'll be able to integrate this with your new Apache::Benchmark
module. I haven't had time to look over yours fully, but I'm thinking your
module will be a layer around this. Currently Apache::Benchmark uses ab,
right? This module almost completely replaces ab. There are a few features
that still need to be added.
Yup, cool. In fact you are welcome to take over it :) Apache::Benchmark
shouldn't be depenfing on the actual engine used for Benchmarking. One
should be able to plug any engine instead of ab.
Here are the first few sections of the manual. Download the full package at
http://adiraj.org/sw/ApacheBench/ApacheBench-0.5.tar.gz. Enjoy.
-Adi
---
NAME
ApacheBench - Perl API for Apache benchmarking and
regression testing.
SYNOPSIS
use ApacheBench;
my $b = ApacheBench-new;
# global configuration
$b-config({
concurrency = 5,
priority = "run_priority",
});
# add sequence(s) of URLs to request
$b-add({
repeat= 10,
cookie= ["Login_Cookie=b3dcc9bac34b7e60;"],
urls = ["http://localhost/one",
"http://localhost/two"], postdata = [undef, undef],
order = "depth_first",
});
my $regress = $b-execute;
# calculate hits/sec == ($#urls+1)*$n*1000 / total_time
print (2*10*1000/$regress-{"total_time"})." req/sec\n";
# dump the entire regression hash (WARNING, this could be a LOT OF
DATA)
use Data::Dumper;
my $d = Data::Dumper-new([$regress]);
print $d-Dumpxs;
GOALS
This project is meant to be the foundation for a complete
benchmarking and regression testing suite for an advanced,
transaction-based mod_perl site. We need to be able to
stress our server to its limit while also having a way to
verify the HTTP responses for correctness. Since our site
is transaction-based (as opposed to content-based), we
needed to extend the single-URL ab model to a multiple-URL
sequence model.
ApacheBench is based on the Apache 1.3.12 ab code
(src/support/ab.c).
Note: although this tool was designed to be used on an
Apache mod_perl site, it is generally applicable to any
HTTP-compliant server. Beware, however, that it sends a
high volume of HTTP requests in a very short period of
time, which may overwhelm some weaker HTTP server
platforms like NT/IIS.
DESCRIPTION
ApacheBench sends sequences of HTTP requests to an HTTP
server and keeps track of the time taken to receive a
response, the data that was returned, the size of the data
that was returned, and various other bits of information.
Since it is implemented in C, it sends HTTP requests in a
tight loop which can stress your server to 100% capacity,
especially if invoked in multiple concurrent instances.
It gives accurate time measurements down to the
millisecond for each HTTP request-response interval.
Included is a simplified re-implementation of ab using the
ApacheBench Perl API. This should help get you started
with ApacheBench.
METHODS
new()
The constructor. It takes no arguments.
config({ %global_params })
Global configuration method. Should only be invoked
once, else previous configuration parameters will be
clobbered. See the global configuration section for
details on how %global_params should be structured.
add({ %run_params })
Run configuration method. Can be invoked multiple
times. Each invocation will register a new benchmark
run to be
New module cadidate Apache::AddHostPath
I have written a new PerlTransHandler module which I currently calling Apache::AddHostPath. It was written to solve a problem I am having in an application I am writing, however if others think it might be usefull and there isn't already something out there that does it, I'd be more than happy to add it to CPAN. The problem I was trying to solve was that I have 11+ domains, (each of which may have additional sub-domains besides "www") that I wish to host from one single apache server and without using Virtual Hosts. The reason I don't want to use Virtual Hosts is that I want to be able to inherit things like images, cgi scripts, stylesheets, javascript, etc.. between domains and sub-domains without having to do weird symbolic links, or even having to mess with httpd.conf. I also want to be able to add domains and sub-domains without changing the config. Point the domain and play. :-) For example not all of the domains are in the same top level domain and I may want to share the same style sheets between all of my .com domains but use a different one for .org domains. Additionally any of the specific .org domains (or Sub-Domains) could override this stylesheet with their own. Essentially the module implements Apache's URI translation phase by attempting to use some or all of the URL hostname and port number as the base of the URI. For example: If a user requested: http://www.cvsroot.org/images/logo.gif My module would attempt all of the following combinations, in this order, until if found the best match (best match being defined as the first one to return true to (-f $filename or -d $filename)): $doc_root/org/cvsroot/www/80/images/logo.gif $doc_root/org/cvsroot/www/images/logo.gif $doc_root/org/cvsroot/images/logo.gif $doc_root/org/images/logo.gif $doc_root/images/logo.gif $doc_root/org/cvsroot/www/80/images $doc_root/org/cvsroot/www/images $doc_root/org/cvsroot/images $doc_root/org/images $doc_root/images $doc_root/org/cvsroot/www/80/ $doc_root/org/cvsroot/www/ $doc_root/org/cvsroot/ $doc_root/org/ $doc_root/ (Failing this it will return DECLINED) When it finds a match it will tack the portions of the original URI which had been removed for testing back onto the full path (Thereby preserving any extra path info, virtual documents, etc...) and sets the $r-filename() For example, in the above example, if it had selected '$doc_root/org/images' as the first match, then it would set the $r-filename to '$doc_root/org/images/logo.gif' even though I already found out it didn't exist. It does this because of things like extra path info on cgi scripts and virtual documents returned by content handlers. Thus relying on the content handler to do any real validation of the URI filename. I have several questions for the mod_perl community: 1) Would this be usefull to the community? (assuming there isn't already a mod to do this) 2) What about the name? 3) Should I be changing $r-uri() instead, thus allowing additional TransHandlers? Or maybe setting both? 4) Any ideas for improvement? The module is already written and seems to work ok. I still need to write docs and packaging if I submit to CPAN, but the module itself is only about 25 lines of code. Thanks in advance, -Robert Jenks [EMAIL PROTECTED]
ANNOUNCE: Apache::Compress 1.002 (new module)
Hi all, The URL http://forum.swarthmore.edu/~ken/modules/archive/Apache-Compress-1.002.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-Compress-1.002.tar.gz size: 10708 bytes md5: 7fef7de82d46083a1b0f2ea1492d2faf Here's the documentation. I'd appreciate any feedback from people who use the module, if only to tell me that it works or doesn't work. --- NAME Apache::Compress - Auto-compress web files with Gzip SYNOPSIS PerlModule Apache::Compress # Compress regular files FilesMatch "\.blah$" PerlHandler Apache::Compress /FilesMatch # Compress output of Perl scripts PerlModule Apache::Filter FilesMatch "\.pl$" PerlSetVar Filter on PerlHandler Apache::RegistryFilter Apache::Compress /FilesMatch DESCRIPTION This module lets you send the content of an HTTP response as gzip- compressed data. Certain browsers (Netscape, IE) can request content compression via the `Content-Encoding' header. This can speed things up if you're sending large files to your users through slow connections. Browsers that don't request gzipped data will receive regular noncompressed data. This module is compatibile with Apache::Filter, so you can compress the output of other content-generators. TO DO Compress::Zlib provides a facility for buffering output until there's enough data for efficient compression. Currently we don't take advantage of this facility, we simply compress the whole content body at once. We could achieve better memory usage if we changed this (at a small cost to the compression ratio). See Eagle book, p.185. AUTHOR Ken Williams, [EMAIL PROTECTED] Partially based on the work of several modules, like Doug MacEachern's Apache::Gzip (in the Eagle book but not on CPAN), Andreas Koenig's Apache::GzipChain, and an unreleased module by Geoffrey Young and Philippe Chiasson. SEE ALSO perl(1), mod_perl(1), Apache::Filter(3)
[new module] Apache::PageKit
I have an addition for the Apache/Perl Module List, under PerlHandler's PageKit cmpOApplication framework w/ HTML::Template TJMATHER Here is a brief description of the module: PageKit is a set of Perl modules that provides an application framework based on mod_perl and HTML::Template. It is based on the Model/View/Controller approach to design, with complete seperation of Perl from HTML. It includes session management, authentication, form validation, sticky html forms, multiple views, modules and includes, and a content management system.
Re: [new module] Apache::PageKit
On Tue, 15 Aug 2000, T.J. Mather wrote: I have an addition for the Apache/Perl Module List, under PerlHandler's PageKit cmpOApplication framework w/ HTML::Template TJMATHER Here is a brief description of the module: PageKit is a set of Perl modules that provides an application framework based on mod_perl and HTML::Template. It is based on the Model/View/Controller approach to design, with complete seperation of Perl from HTML. It includes session management, authentication, form validation, sticky html forms, multiple views, modules and includes, and a content management system. Can you expand on the functionality of the CMS part? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: [new module] Apache::PageKit
I got a couple of e-mails asking where this module could be found. I plan to release the module in a few days on CPAN. I will make an announcement on this list when I do. -TJ Mather
Re: [new module] Apache::PageKit
Here is a brief description of the module: PageKit is a set of Perl modules that provides an application framework based on mod_perl and HTML::Template. It is based on the Model/View/Controller approach to design, with complete seperation of Perl from HTML. It includes session management, authentication, form validation, sticky html forms, multiple views, modules and includes, and a content management system. Can you expand on the functionality of the CMS part? For now, the CMS part is really simple. There are links on every page to edit the HTML template components, if the user has permission to edit. These links link to an edit page which edits the HTML template using one big textarea box. What would be much cooler would be to use XML and a content editor that would translate an XML file into HTML form elements for places in the XML document that the user can edit. There is an interesting chapter (7) in Open Source Linux Web Programming on this. I am moving this discussion to [EMAIL PROTECTED], which is a newly created list for discussing Apache::PageKit. To subscribe, go to http://lists.sourceforge.net/mailman/listinfo/pagekit-users -TJ
[New Module] Apache::Motd
I wrote an Apache Perl Module that I think can be of use to others
who maintain webservers and once in a while have to notify web users
with an urgent message. This module is currently being on the servers
I maintain.
The proposed module name is Apache::Motd (Message of the Day). It
basically mimics the functionality of the motd on UNIX systems. If this
feature already exist, then I guess we can ignore this one, otherwise
I can upload to CPAN.
This module allows you to display a message before the visitor enters
your site without the need to modify webpages or web application
code/logic. The message can be a "Server Going Down in So many hours",
"Terms of Use", "News Flashes",etc. Once the visitor gets the message,
a cookie is set and the visitor is redirected to their original URI
after N seconds.
Comments/Suggestions??
Thanks,
-Carlos
Here is the code and POD.
package Apache::Motd;
use strict;
use vars qw($VERSION);
$VERSION = '0.01';
use Apache;
use Apache::Cookie;
use Apache::Constants qw(:common);
sub handler {
my $r= shift;
my $uri = $r-uri;
my $cn = $r-dir_config('CookieName') || 'seenMOTD';
my $file = $r-dir_config('MessageFile')|| 0;
my $exp = $r-dir_config('ExpireCookie') || '+1d';
my $sec = $r-dir_config('RedirectInSecs') || 10;
unless ($file) {
$r-log_error("Apache::Motd::Error : No Message File
Specified!");
return SERVER_ERROR;
}
return OK unless $r-is_initial_req;
## Lookup cookie state
my $cookies = Apache::Cookie-new($r)-parse;
if (my $c = $cookies-{$cn}) {
my $cv = $c-value;
return OK if $cv;
}
## Apparently this is your first visit
## Prepare cookie information
my $cookie = Apache::Cookie-new($r,
-name = $cn,-value = '1',-expires = $exp );
$cookie-bake;
## Print message $file or return custom server error
unless (open MSG,$file) {
$r-log_error("Apache::Motd::Error : Unable to load message:
$file");
return SERVER_ERROR;
}
## Slurp message $file
my $msg = "";
{
local $/;
$msg = MSG;
}
close MSG;
$msg =~ s/VAR_URI/$uri/g;
$msg =~ s/VAR_REDIRECT/$sec/;
$r-send_http_header('text/html');
$r-print($msg);
return DONE;
}
1;
__END__
=head1 NAME
Apache::Motd - Mimic motd (Message of the Day) on a webserver
=head1 SYNOPSIS
httpd.conf: (in Server, Location, Directory, Files)
PerlPostHeaderParserHandler Apache::Motd
PerlSetVar MessageFile /path/to/message/file
---optional (if you are satisified with the defaults)---
PerlSetVar RedirectInSecs N
PerlSetVar CookieName
PerlSetVar ExpireCookie
=head1 DESCRIPTION
Apache::Motd allows you to force/display a message before the
visitor enters your site without the need to modify webpages or
web application code/logic. The message can be a "Server Going
Down in So many hours", "Terms of Use", "News Flashes",etc.
Once the visitor gets the message, a cookie is set and the visitor
is redirected to their original URI after N seconds.
All variables except MessageFile are optional.
RedirectInSecs- the number of secs to wait before
redirecting to original URI
[Default: 10]
CookieName- the name of the cookie, value is set to 1
[Default: seenMOTD]
ExpireCookie - exipration time of cookie
[Default: +1d i.e. one day]
MessageFile - filesystem path to the file** containing the
message
**file: the file *should* be an html file with the following
requirements.
1. The message file should include a meta tag that handles the
redirect like so:
a meta http-equiv="Refresh"
content="VAR_REDIRECT;url=URI"
where the VAR_REDIRECT will be replaced by the value of
the variable RedirectInSecs and VAR_URI with the original
URI.
Ommiting the meta tag will prevent the user from being
redirected.
VAR_URI can also be used as a "click here to prceed" link,
if
the user chooses not to wait.
Example: a href="URI"click to proceed/a
See sample provided: motd.txt
=head1 REQUIREMENTS
Apache::Cookie
But I can (might) illiminate this requirement if (when) I
implement my own parse incoming header and look for CookieName
routine.
=head1 SEE ALSO
perl(1), mod_perl(1), Apache(3)
=head1 AUTHOR
Carlos Ramirez [EMAIL PROTECTED]
=head1 COPYRIGHT
Copyright 2000 Carlos Ramirez - all rights reserved.
This library is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
=cut
[new module] Apache::Regex
Hi all... I posted to the list a little while ago a simple regular expression PerlHandler implementation. I've cleaned it up since then and thought I might post it to CPAN if there is any interest. I was thinking of Apache::Regex as the release name. I know it's a basic module, and people who need the functionality usually do it themselves, but... Apache::Regex accepts PerlAddVar directives and applies s/$change/$to/eeg the requested HTML file on a line by line basis. Features include: Apache::Filter aware, accepts multiple change/to pairs, only tries to process HTML files. It requires mod_perl 1.24. While overhead intensive, a I originally wrote it for a friend who wanted to be able to use a js enabled page in a plaintext version of the site without having to maintain two pages. Since the plaintext page requests are minimal, the added overhead is negligable. I guess I can see it as also being an easy way to migrate a site when a company changes names once a week :) Anyway, the pre-release can be seen at http://morpheus.laserlink.net/~gyoung/modules/Apache-Regex-0.01.tar.gz constructive comments welcome --Geoff
[new module] Apache::Dispatch
hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a Location restriction and try to call Foo-doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit-handler() or Foo-doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff
Re: [new module] Apache::Dispatch
On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. How Randal used to say: Dangerous, Willis? or was it Robinson :) Personally I'm against this idea. Unless you allow only a list of specified Module::method (s), but even then things will get modified the original intention forgotten, systems hacked and ruined. * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a Location restriction and try to call Foo-doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit-handler() or Foo-doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [new module] Apache::Dispatch
On Mon, 5 Jun 2000, Stas Bekman wrote: On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. It shouldn't be dangerous at all if you specify: PerlSetVar DispatchPrefix MyModule Then http://localhost/Foo/bar calls MyModule::Foo-bar() -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RE: [new module] Apache::Dispatch
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 12:19 PM To: Geoffrey Young Cc: '[EMAIL PROTECTED]'; 'Vivek Khera'; 'Matt Sergeant' Subject: Re: [new module] Apache::Dispatch On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. well, it was the article in this month's LJ that made me think of it again... http://www2.linuxjournal.com/lj-issues/issue74/4002.html of course, while I don't share his views stated in the third and fourth paragraphs, I thought answersing those types of concerns would be a benefit... You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. How Randal used to say: Dangerous, Willis? or was it Robinson :) Danger Will Robinson :) Personally I'm against this idea. Unless you allow only a list of specified Module::method (s), but even then things will get modified the original intention forgotten, systems hacked and ruined. ok, I never claimed to be a security expert, and we certainly don't want to expose mod_perl or give it a bad name. However, if the client/user uses the module parameters to expose his system, does that mean that the module is a bad idea? but I don't see that by allowing only Apache:: modules adds a security risk (but I don't tear apart systems for a living :) --Geoff * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a Location restriction and try to call Foo-doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit-handler() or Foo-doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: [new module] Apache::Dispatch
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 12:25 PM To: Stas Bekman Cc: Geoffrey Young; '[EMAIL PROTECTED]'; 'Vivek Khera' Subject: Re: [new module] Apache::Dispatch On Mon, 5 Jun 2000, Stas Bekman wrote: On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. It shouldn't be dangerous at all if you specify: PerlSetVar DispatchPrefix MyModule Then http://localhost/Foo/bar calls MyModule::Foo-bar() oh, I hadn't thought of using that combination. I guess that would also hide the full package names from the outside and would add an extra level of security... -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
New Module (was Re: RFC: Apache::Request::Forms (or something similar))
I have my own module for doing this job, sorry I missed many
posts of this thread but here is what I do:
- The target is automatically : add , update, select data
from a table reading data typed by the user.
- I didn't want to use the Apache api, so it even can be
used out of apache, so I called it : Persistence::DBI
thought I don't like this name much.
In This example I work with HTML::Mason, but as
I said before it can be used from whatever thingie, even
out of the web.
I'm using currently this in production sites and it saves
me a lot of work.
EXAMPLE OF CODE:
It's a little harder than this but you'll get the idea:
##customer.html###3
%init
# Make the object
my $customer=Persistence::DBI-open(
table = 'customers',
field_id = 'idCustomer'
field_data = \%ARGS
);
if (defined $_delete) {
$customer-delete;
}
/%init
## The html form is this way:
form
input type="text" name="name" value="% $customer-name %"
input type="text" name="phone" value="% $customer-phone %"
input type="submit" name="_save" value="save"
% if (defined $customer-idCustomer) {
input type="hidden" name="idCustomer"
value="% $customer-idCustomer %"
input type="submit" name="_delete" value="delete"
% }
/form
It works this way:
- if you supply the value of the id field it does a select
- if you supply all the fields but the id, it does an insert
- if you supply id and fields it does an update
Before calling the object you can check the values supplied
by the user to verify the values are correct.
If you modify values of the object it updates the data.
I'll accept name changes and I'll send the module to
whoever wants it. I checked it with MySQL and SQL server.
The module come with pods and it installs fine like any
other module.It needs the field_id be auto increment.
--
- frankie -
[new module development] Apache::Ping
hi all...
well, this isn't a new module quite yet... I've been toying with
the idea of a module that does automatic server monitoring. I know there
must be programs out there that do this, and the guide has some examples,
but I was interested in creating a module add-in that would take care of
things with minimal intervention (as in PerlModule Apache::Ping and that's
all)...
I'm not really a systems person, so I don't get all the intricicies of
forking, daemons, and the like, but here's a skeleton that seems to work...
Does anyone think this is a worthy endeavor? Are there some inherent
dangers here that should mentioned?
--Geoff
package Apache::Ping;
use 5.004;
use mod_perl 1.23;
use LWP::UserAgent;
use strict;
$SIG{CHLD} = 'IGNORE';
my $warmup = 10;
my $wait = 10;
my $restart = "/usr/local/apache/apachectl restart";
my $url = "http://localhost/perl-status";
defined (my $kid = fork) or die "Cannot fork: $!\n";
unless ($kid) {
close STDIN;
close STDOUT;
close STDERR;
open STDIN, '/dev/null'|| die "Can't read /dev/null: $!";
open STDOUT, '/dev/null' || die "Can't write to /dev/null: $!";
open STDERR, '/dev/null' || die "Can't write to /dev/null: $!";
sleep($warmup);
while(1) {
my $ua = new LWP::UserAgent;
my $req = new HTTP::Request (GET = $url);
my $res = $ua-request($req);
if ($res-is_success) {
sleep($wait);
} else {
system($restart);
CORE::exit(0);
}
}
close FH;
CORE::exit(0);
}
1;
RE: [new module] proposal Apache::DebugHeaders
-Original Message- From: Graham Barr [mailto:[EMAIL PROTECTED]] Sent: Friday, March 31, 2000 3:12 AM To: Geoffrey Young Cc: 'Ask Bjoern Hansen'; '[EMAIL PROTECTED]'; 'Stas Bekman'; 'darren chamberlain'; '[EMAIL PROTECTED]' Subject: Re: [new module] proposal Apache::DebugHeaders On Thu, Mar 30, 2000 at 04:07:38PM -0500, Geoffrey Young wrote: Hey, I'm not trying to redo anyone's work or step on toes... I am sure your not, but on the other hand when two modules are so close in functionality it can help to merge them. There are several reasons why this can be benificial, not least that it cuts down on duplication of effort I looked at DumpHeaders and thought that my stuff didn't quite fit in becuase: 1) it's longer - DumpHeaders is short and sweet That;'s no reason why it cannot be extended. Like many modules on CPAN DumpHeaders was written to meet a specific task. That does not mean enhancements cannot be added. I meant that as a compliment :) 2) it's my attempt at trying to make something OO and extensible And I would encourage everyone to take a learning cycle, it's fun. 3) it has functionality that DumpHeaders doesn't So extend it. (and doesn't 'allow' for by name) Huh? DumpHeaders dumps the request headers - it would seem that to add functionality outside of that at least calls for a name change. Maybe? I dunno... 4) it allows you to track stuff throughout the request cycle (for modules that change them) extend Here's the code (minus documentation - if it isn't appropriate it isn't. Let me know what you think - I'm open to anything... It seems to me that these two modules are VERY close in many aspects yet both have something the other does not. The two main things I see in DumpHeaders that are not in yours are the ability to specify a log file (I think yours goes to the standard apache log) and the ability to specify which IP addresses to dump headers for, this is VERY useful when trying to debug a problem on a live site that only a few people see, dumping all headers is just too much. So that said, what would it take to add these two features to yours ? not much work, I suppose - I'm certainly willing to do it. I did like the IP feature when I saw it, and thought of adding it. The file feature doesn't strike me, but if folks use it then fine. I it could do that, and support the PerlSetVars that DumpHeaders uses then it could just be a drop in replacement. Ok... Since Ask has seniority :) I'll defer to him on this one. I can either add his code or we can extend DumpHeaders together... either way, it's been a good experience for me... --Geoff Graham.
Re: [new module] proposal Apache::DebugHeaders
On Thu, Mar 30, 2000 at 04:07:38PM -0500, Geoffrey Young wrote: Hey, I'm not trying to redo anyone's work or step on toes... I am sure your not, but on the other hand when two modules are so close in functionality it can help to merge them. There are several reasons why this can be benificial, not least that it cuts down on duplication of effort I looked at DumpHeaders and thought that my stuff didn't quite fit in becuase: 1) it's longer - DumpHeaders is short and sweet That;'s no reason why it cannot be extended. Like many modules on CPAN DumpHeaders was written to meet a specific task. That does not mean enhancements cannot be added. 2) it's my attempt at trying to make something OO and extensible And I would encourage everyone to take a learning cycle, it's fun. 3) it has functionality that DumpHeaders doesn't So extend it. (and doesn't 'allow' for by name) Huh? 4) it allows you to track stuff throughout the request cycle (for modules that change them) extend Here's the code (minus documentation - if it isn't appropriate it isn't. Let me know what you think - I'm open to anything... It seems to me that these two modules are VERY close in many aspects yet both have something the other does not. The two main things I see in DumpHeaders that are not in yours are the ability to specify a log file (I think yours goes to the standard apache log) and the ability to specify which IP addresses to dump headers for, this is VERY useful when trying to debug a problem on a live site that only a few people see, dumping all headers is just too much. So that said, what would it take to add these two features to yours ? I it could do that, and support the PerlSetVars that DumpHeaders uses then it could just be a drop in replacement. Graham.
Re: [new module] proposal Apache::DebugHeaders
On Thu, 30 Mar 2000, Geoffrey Young wrote: Hi all... I finished an alpha of DebugHeaders (now potentially called DebugInfo) - here's the description. I still think it would fit much better as patches to Apache::DumpHeaders. :) They are doing pretty much the same thing. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
RE: [new module] proposal Apache::DebugHeaders
r stack
#-
if (@phases) {
push_on_stack($r, 'pnotes', @phases);
return 1;
}
#-
# otherwise, just print $r-notes in a pretty format
#-
my $pnotes = $r-pnotes;
print STDERR "Debug pnotes for $uri during " .
$r-notes('PERL_CUR_HOOK') . "\n";
my %hash = %$pnotes;
foreach my $field (sort keys %hash) {
my $value = $hash{$field};
my $type = ref $value;
if ($type eq 'SCALAR') {
print STDERR "\t$field = $value\n";
} elsif ($type eq 'HASH') {
my %hash = %$value;
print STDERR "\t$field =\n";
foreach my $key (sort keys %hash) {
print STDERR "\t\t $key = $hash{$key}\n";
}
} elsif ($type eq 'ARRAY') {
my @array = @$value;
print STDERR "\t$field = $array[0]\n";
for (my $i=1;$i @array; $i++) {
print STDERR "\t\t\t\t= $array[$i]\n";
}
} elsif ($type) {
# we don't handle globs or other references yet...
print STDERR "\t$field = $type thingy\n";
} else {
print STDERR "\t$field = $value\n";
}
}
#-
# wrap up...
#-
$log-info("Exiting Apache::DebugInfo::pnotes")
if $Apache::DebugInfo::DEBUG;
# return declined so that Apache::DebugInfo doesn't short circuit
# Perl*Handlers that stop the chain after the first OK (like
# PerlTransHandler
return DECLINED;
}
sub pid {
#-
# I know this is a waste of code for just printing $$, but I thought
# it would be nice to have a consistent interface. whatever...
#-
my $self = shift;
my @phases= @_;
my $r = $self-{request};
my $log = $self-{log};
my $uri = $r-uri;
$log-info("Using Apache::DebugInfo::pid")
if $Apache::DebugInfo::DEBUG;
#-
# if there are arguments, push the routine onto the handler stack
#-
if (@phases) {
push_on_stack($r, 'pid', @phases);
return 1;
}
#-
# otherwise, just print the pid
#-
print STDERR "Debug PID for $uri during " .
$r-notes('PERL_CUR_HOOK') . "\n\t$$\n";
#-
# wrap up...
#-
$log-info("Exiting Apache::DebugInfo::pid")
if $Apache::DebugInfo::DEBUG;
# return declined so that Apache::DebugInfo doesn't short circuit
# Perl*Handlers that stop the chain after the first OK (like
# PerlTransHandler
# you really need help if you call this one more than once,
# though...
return DECLINED;
}
1;
__END__
-Original Message-
From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 30, 2000 3:19 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'; 'Stas Bekman'; 'darren chamberlain';
'[EMAIL PROTECTED]'
Subject: Re: [new module] proposal Apache::DebugHeaders
On Thu, 30 Mar 2000, Geoffrey Young wrote:
Hi all...
I finished an alpha of DebugHeaders (now potentially called
DebugInfo) -
here's the description.
I still think it would fit much better as patches to
Apache::DumpHeaders.
:)
They are doing pretty much the same thing.
- ask
--
ask bjoern hansen - http://www.netcetera.dk/~ask/
more than 70M impressions per day, http://valueclick.com
Re: [new module] proposal Apache::DebugHeaders
On Wed, 29 Mar 2000, Francesc Guasch wrote: A very easy way of create Makefile.PL and module files and directories is typing this: h2xs -X -n My::Object Please don't do that for mod_perl. You get autoloading that way, which means mod_perl can't load the methods at start time, which means they aren't shared. Use: h2xs -X -A -C -n My::Object -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [new module] proposal Apache::DebugHeaders
On Tue, 28 Mar 2000, Geoffrey Young wrote: ok, this isn't all that clever, but recently I got tired of writing loops of warnings to debug headers_in and headers_out over and over again... Then you should look at the Apache::DumpHeaders module. :) Major feature is that it can be configured to only dump traffic from certain IP addresses. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
RE: [new module] proposal Apache::DebugHeaders
actually, http://perl.apache.org/src/apache-modlist.html recommends h2xs -AX -n Apache::YourPackageName what's the -C option - it isn't in my perldoc h2xs? --Geoff -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 29, 2000 4:40 AM To: Francesc Guasch Cc: '[EMAIL PROTECTED]' Subject: Re: [new module] proposal Apache::DebugHeaders On Wed, 29 Mar 2000, Francesc Guasch wrote: A very easy way of create Makefile.PL and module files and directories is typing this: h2xs -X -n My::Object Please don't do that for mod_perl. You get autoloading that way, which means mod_perl can't load the methods at start time, which means they aren't shared. Use: h2xs -X -A -C -n My::Object -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RE: [new module] proposal Apache::DebugHeaders
-Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 29, 2000 6:30 AM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: Re: [new module] proposal Apache::DebugHeaders On Tue, 28 Mar 2000, Geoffrey Young wrote: ok, this isn't all that clever, but recently I got tired of writing loops of warnings to debug headers_in and headers_out over and over again... Then you should look at the Apache::DumpHeaders module. :) whoops - I missed that one (looks recent, too :) actually, since posting the code I've expanded it to itterate through notes and pnotes as well, and started making it object oriented so it can either default to the handler and make Perl*Handler phase choices for you, or you can call any of the dump routines on the fly... do these sound like value added features? Should they be incorporated into DumpHeaders or do the warrant their own module? I renamed the one I am working on Apache::DebugLog... Major feature is that it can be configured to only dump traffic from certain IP addresses. this looks like a nice feature - I'll have to look at it some more... --Geoff - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
RE: [new module] proposal Apache::DebugHeaders
On Wed, 29 Mar 2000, Geoffrey Young wrote: actually, http://perl.apache.org/src/apache-modlist.html recommends h2xs -AX -n Apache::YourPackageName what's the -C option - it isn't in my perldoc h2xs? It was supposed to be -c, shoot the typist :) Not really relevant with -X, but I always use it anyway, because I prefer to not have any of the crappy cruft that h2xs gives you by default. (I use -P too quite often). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
[new module] proposal Apache::DebugHeaders
ok, this isn't all that clever, but recently I got tired of writing loops of
warnings to debug headers_in and headers_out over and over again...
all this one does is spit out headers_in in the init phase and headers_out
in the cleanup phase. Not terribly extensible, but perhaps practical
if anyone thinks it worthy of CPAN, I'll throw it up. If folks are real
interested, maybe it can be altered somewhat to start an Apache::Debug::
series with stuff working toward similar ends...
Otherwise, feel free to discard it at will...
--Geoff
package Apache::DebugHeaders;
#-
#
# usage: PerlInitHandler Apache::DebugHeaders
#
#-
use 5.004;
use mod_perl 1.21;
use Apache::Constants qw( OK );
use Apache::Log;
use strict;
$Apache::DebugHeaders::VERSION = '0.01';
# set debug level
# 0 - messages at info or debug log levels
# 1 - verbose output at info or debug log levels
$Apache::DebugHeaders::DEBUG = 1;
sub handler {
#-
# initialize request object
#-
my $r = shift;
my $log = $r-server-log;
#-
# do some preliminary stuff...
#-
$log-info("Using Apache::DebugHeaders")
if $Apache::DebugHeaders::DEBUG;
#-
# push the PerlFixupHander and PerlCleanupHandler onto the stack
#-
$r-push_handlers(PerlInitHandler= 'Apache::DebugHeaders::in');
$r-push_handlers(PerlCleanupHandler = 'Apache::DebugHeaders::out');
#-
# wrap up...
#-
$log-info("Exiting Apache::DebugHeaders")
if $Apache::DebugHeaders::DEBUG;
return OK;
}
sub in {
#-
# initialize request object
#-
my $r = shift;
my $log = $r-server-log;
#-
# print $r-headers_in in a pretty format
#-
my $headers_in = $r-headers_in;
$log-info("headers_in:");
$headers_in-do(sub {
my ($field, $value) = @_;
if ($field =~ m/Cookie/) {
my @values = split /; /, $value;
foreach my $cookie (@values) {
$log-info("\tfield = $field, value = $cookie");
}
}
else {
$log-info("\tfield = $field, value = $value");
}
1;
});
#-
# wrap up...
#-
return OK;
}
sub out {
#-
# initialize request object
#-
my $r = shift;
my $log = $r-server-log;
#-
# print $r-headers_out in a pretty format
#-
my $headers_out = $r-headers_out;
$log-info("headers_out:");
$headers_out-do(sub {
my ($field, $value) = @_;
if ($field =~ m/Cookie/) {
my @values = split /;/, $value;
$log-info("\tfield = $field, value = $values[0]");
for (my $i=1;$i @values; $i++) {
$log-info("\t\t\t\t $values[$i]");
}
}
else {
$log-info("\tfield = $field, value = $value");
}
1;
});
#-
# wrap up...
#-
return OK;
}
1;
__END__
=head1 NAME
Apache::DebugHeaders - log the incoming and outbound HTTP headers
=head1 SYNOPSIS
httpd.conf:
PerlInitHandler Apache::DebugHeaders
=head1 DESCRIPTION
Apache::DebugHeaders merely itterates through $r-headers_in and
$r-headers_out and prints them to the error_log. It provides an
easy way to quickly enable and disable debugging behavior - that's
all.
=head1 NOTES
Verbose debugging is enabled by setting the variable
$Apache::DebugHeaders::DEBUG=1 to or greater. To turn off all debug
information (including the header info, which is the point of this
module), set your apache LogLevel above info level.
This is alpha software, and as such has not been tested on multiple
platforms or environments. It requires PERL_INIT=1,
Re: [new module] proposal Apache::DebugHeaders
Hi, Geoff
ok, this isn't all that clever, but recently I got tired of writing
loops of warnings to debug headers_in and headers_out over and over
again...
all this one does is spit out headers_in in the init phase and headers_out
in the cleanup phase. Not terribly extensible, but perhaps practical
if anyone thinks it worthy of CPAN, I'll throw it up. If folks are real
interested, maybe it can be altered somewhat to start an Apache::Debug::
series with stuff working toward similar ends...
Every code snippet that you produce and find it useful, at some point
might be useful to other programmers. Therefore it's a good idea to make
it available even if there is no interest when you post it (I don't say
there is not :) So if no one replies with naming suggestion or else, go
ahead and release it on CPAN.
Did you know that CPAN tolerates even the packages with no Makefile.PL? I
don't try to disencourage you to write Makefile.PL (feel free to "steal"
one from your favorite module), but if you really cannot build yours
release it as it is. It still might save one of us days of work, which in
return might give you something that you need.
Otherwise, feel free to discard it at will...
--Geoff
package Apache::DebugHeaders;
#-
#
# usage: PerlInitHandler Apache::DebugHeaders
#
#-
use 5.004;
use mod_perl 1.21;
use Apache::Constants qw( OK );
use Apache::Log;
use strict;
$Apache::DebugHeaders::VERSION = '0.01';
# set debug level
# 0 - messages at info or debug log levels
# 1 - verbose output at info or debug log levels
$Apache::DebugHeaders::DEBUG = 1;
sub handler {
#-
# initialize request object
#-
my $r = shift;
my $log = $r-server-log;
#-
# do some preliminary stuff...
#-
$log-info("Using Apache::DebugHeaders")
if $Apache::DebugHeaders::DEBUG;
#-
# push the PerlFixupHander and PerlCleanupHandler onto the stack
#-
$r-push_handlers(PerlInitHandler= 'Apache::DebugHeaders::in');
$r-push_handlers(PerlCleanupHandler = 'Apache::DebugHeaders::out');
#-
# wrap up...
#-
$log-info("Exiting Apache::DebugHeaders")
if $Apache::DebugHeaders::DEBUG;
return OK;
}
sub in {
#-
# initialize request object
#-
my $r = shift;
my $log = $r-server-log;
#-
# print $r-headers_in in a pretty format
#-
my $headers_in = $r-headers_in;
$log-info("headers_in:");
$headers_in-do(sub {
my ($field, $value) = @_;
if ($field =~ m/Cookie/) {
my @values = split /; /, $value;
foreach my $cookie (@values) {
$log-info("\tfield = $field, value = $cookie");
}
}
else {
$log-info("\tfield = $field, value = $value");
}
1;
});
#-
# wrap up...
#-
return OK;
}
sub out {
#-
# initialize request object
#-
my $r = shift;
my $log = $r-server-log;
#-
# print $r-headers_out in a pretty format
#-
my $headers_out = $r-headers_out;
$log-info("headers_out:");
$headers_out-do(sub {
my ($field, $value) = @_;
if ($field =~ m/Cookie/) {
my @values = split /;/, $value;
$log-info("\tfield = $field, value = $values[0]");
for (my $i=1;$i @values; $i++) {
$log-info("\t\t\t\t $values[$i]");
}
}
else {
$log-info("\tfield = $field, value = $value");
}
1;
});
#-
# wrap up...
#-
Re: [new module] proposal Apache::DebugHeaders
Stas Bekman wrote: Did you know that CPAN tolerates even the packages with no Makefile.PL? I don't try to disencourage you to write Makefile.PL (feel free to "steal" one from your favorite module), but if you really cannot build yours release it as it is. It still might save one of us days of work, which in return might give you something that you need. A very easy way of create Makefile.PL and module files and directories is typing this: h2xs -X -n My::Object -- - frankie -
