Re: getting rid of nested sub lexical problem
On Thu, 21 Dec 2000, Doug MacEachern wrote:
On Thu, 19 Oct 2000, Chris Nokleberg wrote:
Following up on my post on this subject a couple of months ago, here is a
proof-of-concept drop-in replacement for Apache::Registry that eliminates
the "my() Scoped Variable in Nested Subroutine" problem.
nice hack!
It requires PERL5OPT = "-d" and PERL5DB = "sub DB::DB {}" environment
variables set when starting the mod_perl-enabled httpd. This enables the
%DB::sub hash table that holds subroutine start and end line info. I
presume that this has some negative (marginal?) impact on performance. If
someone knows of a better way to reliably figure out where a subroutine
starts and ends, please let me know.
there is quite a bit of overhead when -d is enabled. have a look at
Apache::DB.xs, there's in init_debugger() function todo what -d does. if
another method was added to turn it off, after the registry script was
compiled, the overhead would be reduced a great deal.
oooh, cool. I've added this to Apache::DB.xs:
int
stop_debugger()
CODE:
if (PL_perldb) {
PL_perldb = 0;
RETVAL = TRUE;
}
else
RETVAL = FALSE;
OUTPUT:
RETVAL
It appears that setting PL_perldb to zero is all that's required to turn
off the debugger! I thought I might have to fiddle with the symbol tables
but this seems to work.
I've attached the latest version of Apache::NiceRegistry (suggestions
welcome) below. Not sure this is the right thing to do , but I call
Apache::DB::init_debugger directly because I need the return value (don't
want to stop_debugger if it was turned on outside of this handler), and I
don't want the warning that Apache::DB-init produces.
Also, why does Apache::DB unset $Apache::Registry::MarkLine?
Thanks,
Chris
--
package Apache::NiceRegistry;
use base Apache::RegistryNG;
use strict;
use Apache::DB ();
$Apache::Registry::MarkLine = 1;
my %skip_subs = map { $_ = 1 } qw( handler BEGIN END CHECK INIT );
sub compile {
my ($pr, $eval) = @_;
$eval ||= $pr-{'sub'};
my $init_db = Apache::DB::init_debugger();
$pr-SUPER::compile($eval);
Apache::DB::stop_debugger() if $init_db;
my $package = $pr-namespace;
my @lines = split /\n/, $$eval;
foreach my $sub (grep /^$\Qpackage\E/, keys %DB::sub) {
my ($name) = $sub =~ /:([^:]+)$/;
next if $skip_subs{$name};
my ($start, $end) = $DB::sub{$sub} =~ /:(\d+)-(\d+)$/;
$lines[$start + 1] =~ s:(sub[^\{]+\{):$1\{sub\{:;
$lines[$end + 1] =~ s:\}(?!.*\})$:\}\}\}:;
}
$$eval = join "\n", @lines;
$pr-flush_namespace($package);
$pr-SUPER::compile($eval);
}
1;
Re: Apache::DBI and transactions
In case your script makes some db changes "by accident"--if you don't do an explicit rollback or commit at the end, the uncommitted changes will hang around, and the next request may end up committing those changes unwittingly. I rollback at both the beginning and the end of all requests, just to be safe :) --Chris On Thu, 14 Dec 2000, Stas Bekman wrote: I was in the process of updating the Apache::DBI section of the guide with the notes from the latest version of this package, and there is a new section about Transactions. Since I use mysql, it doesn't have transactions so I cannot it's not absolutely clear to me. For example why the script should perform a rollback at the end? Isn't it only for the case where the transaction has failed? Anybody?
Re: How do I redirect STDOUT to a string WAS Using MHonArc insideof mod_perl
FYI this is not mod_perl related. You'll want the IO::String package. If the perl function you are calling is just printing to the default filehandle (which I'm guessing it does), you should be able to just 'select' the IO::String object: my $str; my $str_fh = IO::String-new($str); my $old_fh = select($str_fh); # call MHonArc or whatever here print_stuff() # reset default fh to previous value select($old_fh) if defined $old_fh; --Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing server affinity
I thought about mod_rewrite but I would like this affinity module to handle the job of picking a random/round-robin backend server and setting the cookie itself. That way I don't have any session mgmt code in the backend server; I will just "know" that certain urls are guaranteed to bring the user back to the same box. --Chris On 22 Nov 2000, David Hodgkinson wrote: Chris Nokleberg [EMAIL PROTECTED] writes: Of course, the front-end proxy servers don't have mod_perl, so the TransHandler would have to be written in C (?). Does anyone know of any existing code that does this sort of thing? Or simply well-written C TransHandlers that I could work off of? Is there a better way? How are you doing session management? I'm sure mod_rewrite could peek at the user cookie or mangled URL and redirect accordingly. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
implementing server affinity
Most of our pages are served by identical load-balanced boxes, and it doesn't matter which box serves what. However, a few special pages store a lot of per-user session data. Instead of burdening our db machine to store this data, I would like to use the filesystem. This requires that for these special pages, users are assigned a (random) box and are redirected back to that box on subsequent requests (presumably using a cookie). I know that some of load-balancers support this feature, but it seems like it would be relatively simple and efficient to implement by adding a TransHandler to the front-end proxy server on each box. The proxy would connect to a backend mod_perl httpd on a different box if it needed to, for these special pages only. Of course, the front-end proxy servers don't have mod_perl, so the TransHandler would have to be written in C (?). Does anyone know of any existing code that does this sort of thing? Or simply well-written C TransHandlers that I could work off of? Is there a better way? Thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: frontend proxy really useful?
On Sun, 21 May 2000, G.W. Haywood wrote: You might think that it serves little purpose for a light Apache server simply to pass all requests from a socket through to a heavy mod_perl server, only then to receive the reply and pass it back to the socket. But you don't usually know what is the other side of the socket, and so you don't know how fast the buffer will be emptied. It might take a couple of minutes if the client is on a slow line. Your processes could all be waiting for the socket buffers to be emptied by slow clients, so there may be no free child to serve an incoming request. In that case Apache will just keep spawning new ones (if it's allowed) for any new incoming requests. You could build up a big heap of waiting processes. You will have far less resources consumed by the waiting processes if they are plain Apache children than you will if they are Apache+mod_perl children. So you will be able to spawn more processes, and so serve more incoming requests. But the guide seems to be saying that the speed of the client isn't an issue--the process (proxy _or_ mod_perl) is released as soon as it finishes putting the outputted page into the OS socket buffer. I assume "released" means it can go and serve another request. Am I reading it wrong? "Therefore if you don't use mod_proxy and mod_perl send its data directly to the client, and you have a big socket buffer, the mod_perl process will be released as soon as the last chunk of data will enter the buffer. Just like with mod_proxy, OS will worry to complete the data transfer." Chris
frontend proxy really useful?
I was rereading http://perl.apache.org/guide/scenario.html#Buffering_Feature and was surprised to find: "Therefore if you don't use mod_proxy and mod_perl send its data directly to the client, and you have a big socket buffer, the mod_perl process will be released as soon as the last chunk of data will enter the buffer. Just like with mod_proxy, OS will worry to complete the data transfer." Is there any new information on whether this is the case? If it is, does it make the light frontend buffering proxy technique useless as long as your pages fit in the socket buffer size (256K on Solaris)? (assuming the proxy is just a dumb passthrough to one backend server) Thanks, Chris
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
Someone has asked how to move from registry scripts to perl handlers, this is my attempt to show in details the process. Comments are welcome. In my mind, one of the biggest problems in transitioning from Apache::Registry is the added server configuration complexity. Would it be possible to add a section on the best way to simplify or eliminate the need to modify the conf file for each new handler? Perl sections, etc.? Thanks, Chris -- Chris Nokleberg + Internet Sports Network, Inc. [EMAIL PROTECTED] + http://www.SportsRocket.com/
RE: pool of DB connections ?
So, Tim, what *are* the differences, and when should we should we choose Apache::DBI vs DBI-connect_cached, and why? I think one of the big differences is that Apache::DBI overrides the disconnect method, to prevent accidentally calling disconnect from a mod_perl script. When using connect_cached you have to watch out for this yourself. Also, I had to switch from using Apache::DBI to connect_cached in my Apache::Registry script because of another subtle difference... (from Apache::DBI) # The PerlCleanupHandler is supposed to initiate a rollback after the script has finished if AutoCommit is off. # Note: the PerlCleanupHandler runs after the response has been sent to the client My registry script was using AutoCommit=0 and trying to commit via an END block, but Apache::DBI was rolling back before the END block was executed. Took a while to track this down. Chris - Chris Nokleberg + Internet Sports Network, Inc. [EMAIL PROTECTED] + http://www.SportsRocket.com/
RegistryNG docs?
I'd like have my registry scripts be cached by their filename after resolving symbolic links, and I think subclassing RegistryNG is the cleanest way to accomplish this. Unfortunately, I cannot find any documentation on RegistryNG. Is it ready for prime-time, or should I just hack Registry for now? (using Apache 1.3.9, mod_perl 1.21) Thanks, Chris -- Chris Nokleberg + Internet Sports Network, Inc. [EMAIL PROTECTED] + http://www.SportsRocket.com/
