Re: object not being destroyed in a TemplateToolkit-based handler
"RB" == Robin Berjon [EMAIL PROTECTED] writes: RB At 13:24 08/02/2001 -0500, Vivek Khera wrote: Ok... Upgrade to "Apache/1.3.17 (Unix) mod_perl/1.25_01-dev" fixed the object destroy issue. Yay! RB I'm glad your problem is soved, but does anyone have any idea what RB triggered that problem ? I'm running 1.3.14/1.24_01 and though I'm not Actually, it turned out to be an issue with defining a MACRO causing the stash to not get GC'd by perl. It is not a mod_perl issue at all.
Re: object not being destroyed in a TemplateToolkit-based handler
"PH" == Perrin Harkins [EMAIL PROTECTED] writes: PH Okay, I just tried the code you posted under mod_perl and it worked fine. PH I changed a couple of lines having to do with locations and package names, Ok... Upgrade to "Apache/1.3.17 (Unix) mod_perl/1.25_01-dev" fixed the object destroy issue. Yay! Old versions were Apache 1.3.14 and mod_perl 1.24_02-dev. Why that fixes it, I dunno. (Nor do I care at this point ;-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: object not being destroyed in a TemplateToolkit-based handler
At 13:24 08/02/2001 -0500, Vivek Khera wrote: Ok... Upgrade to "Apache/1.3.17 (Unix) mod_perl/1.25_01-dev" fixed the object destroy issue. Yay! Old versions were Apache 1.3.14 and mod_perl 1.24_02-dev. Why that fixes it, I dunno. (Nor do I care at this point ;-) I'm glad your problem is soved, but does anyone have any idea what triggered that problem ? I'm running 1.3.14/1.24_01 and though I'm not seeing any serious leakage, I'd rather know what can cause it as I probably won't be upgrading my production server too soon. -- robin b. "Windows may be pretty. And easy. But it has no depth or soul. It's like the one-night stand of operating systems. You feel cheap after using it." -- Steph, in User Friendly
Re: object not being destroyed in a TemplateToolkit-based handler
"dc" == darren chamberlain [EMAIL PROTECTED] writes: dc Vivek Khera ([EMAIL PROTECTED]) said something to this effect on 02/06/2001: However, at the end of the template processing, the object is not destroyed; that is, the DESTROY() method is never called, and dc You aren't clear about the scope of $tt; it sounds like a package dc level global, if it's being destroyed when the children exit. $tt is intended to be persistent. TemplateToolkit cleans up its own "stash" of objects after processing a template, but in mod_perl, the stash objects seems to persist, even though they are inaccessible from that stash. I guess I need more explanation for mod_perl folks than I did for TT folks. Here's what happens. $tt is the template toolkit object. I call $tt-process($filename,$vars,$r) to process and output the page to the web client. During the process method, Template Toolkit creates a localized "stash" of template variables. One of those variables is a 'session' object I made. It is created like this: "[% USE s = session %]". Now, when process() is done, it clears out the localized stash. In a regular perl program, this causes the "s" object to be destroyed, and the DESTROY method called. In mod_perl, the object is not destroyed nor is the DESTROY method called until the httpd exits.
Re: object not being destroyed in a TemplateToolkit-based handler
"PH" == Perrin Harkins [EMAIL PROTECTED] writes:
PH Hmmm... If I'm reading the code correctly, what's supposed to happen is
PH that the stash (where your plugin instance lives) gets localized when you
PH call $tt-process() and de-localized at the end, which should result in
PH anything you added to it (with your USE s = session) getting DESTROY-ed.
Ok... here's a mini-plugin that exhibits this behavior, and a command
line script for it. My mod_perl handler is essentially the same as
the command line script, except that $tt is a package "my" variable,
and the $tt-process() is called from the package handler() method.
In mod_perl, I change the goober object's "print" to "warn" so they go
to the error_log file. The destroy message only shows up when httpd
exits.
Does anyone else have issues with TT plugin objects not getting
destroyed under the mod_perl environment? It works as expected in the
command line version below. That is, after process() finishes, the
object goes away.
TT version 2.0
mod_perl 1.24_02-dev
Apache 1.3.14
FreeBSD 4.2-STABLE (from Jan 29)
My/goober.pm:
--cut here--
#! /usr/bin/perl
package My::goober;
use strict;
use base qw( Template::Plugin );
sub new {
my $class = shift;
my $context = shift;
my $id = rand;
print "creating goober object $id\n";
return bless { id = $id, _CONTEXT = $context }, $class;
}
sub DESTROY {
my $self = shift;
print "goober object $self-{id} destroyed\n";
}
1;
--cut here--
and the script to run it on command line:
--cut here--
#!/usr/bin/perl -w
use strict;
use Template;
$| = 1;
my $tt =
Template-new({
PLUGIN_BASE = 'My',
POST_CHOMP = 1,
PRE_CHOMP = 1,
VARIABLES = {
foo = 'hi!',
},
}
)
or die "Template::new failure";
my $template = "EOT";
[% USE g = goober %]
...template output...
[% foo %]
EOT
print "Starting to process template\n";
$tt-process(\$template,undef) or die $tt-error();
print "Template processing done\n";
--cut here--
here's my mod_perl handler:
--cut here--
#! /usr/bin/perl
package MLM::MLMhandler;
use strict;
use 5.005;
use Apache::Constants qw(OK DECLINED NOT_FOUND SERVER_ERROR);
use vars qw($Debug $VERSION);
$Debug ||= 0;
BEGIN {
$VERSION = do { my @r=(q$Revision: 0.1 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r, @r
};
}
use Template;
use Apache::Util;
my $tt =
Template-new({
PRE_PROCESS = 'header.tt',
POST_PROCESS = 'footer.tt',
DEFAULT = 'notfound.html',
ABSOLUTE = 1,
INCLUDE_PATH =
'/home/khera/proj/vk-mlm/website/docs/_templates:/home/khera/proj/vk-mlm/website/docs',
PLUGIN_BASE = 'MLM::Plugins',
VARIABLES =
{
time2str = sub {
return Apache::Util::ht_time(($_[1]||time),($_[0]||'%c'),0);
},
},
})
or die "Template::new failure";
sub handler {
my($r) = @_;
# only works on main request
return DECLINED unless ($r-is_main());
my $subr = $r-lookup_uri($r-uri); # uri is relative to doc root
my $fileName = $subr-filename; # absolute file name
return NOT_FOUND unless -f $fileName; # file not found
#return DECLINED unless -T _; # not a text file
# send headers to the client
$r-send_http_header('text/html');
return OK if $r-header_only(); # HEAD request, so skip out early!
Apache-request($r);# plugins might need it
$tt-process($fileName, undef, $r)
or do { warn $tt-error(); return SERVER_ERROR; };
return OK;
}
1;
--cut here--
Re: object not being destroyed in a TemplateToolkit-based handler
On Wed, 7 Feb 2001, Vivek Khera wrote: Ok... here's a mini-plugin that exhibits this behavior, and a command line script for it. This all looks like it should work, and the plugin object should get destroyed. Until someone finds the source of the problem, you could work around it by keeping your session reference in $r-pnotes instead of the actual plugin object. Then the session will get destroyed at the end of the request even if the plugin object doesn't. - Perrin
Re: object not being destroyed in a TemplateToolkit-based handler
"PH" == Perrin Harkins [EMAIL PROTECTED] writes: PH On Wed, 7 Feb 2001, Vivek Khera wrote: Ok... here's a mini-plugin that exhibits this behavior, and a command line script for it. PH This all looks like it should work, and the plugin object should get PH destroyed. Until someone finds the source of the problem, you could work PH around it by keeping your session reference in $r-pnotes instead of the You and your $r-pnotes()!!! :-) Very useful idea... I think for now I'll just go with a session.finish() method to force the untie manually. Did you (or anyone else) reproduce the non-destroy of my mini-plugin? I'd like to at least know if I'm doing something wrong in mod_perl. I find it disconcerting to have my plugin objects sitting around unused and unreaped, aka, memory leakage. Thanks.
Re: object not being destroyed in a TemplateToolkit-based handler
On Wed, 7 Feb 2001, Vivek Khera wrote: Did you (or anyone else) reproduce the non-destroy of my mini-plugin? I didn't actually run it; just poked through the code. I'd like to at least know if I'm doing something wrong in mod_perl. I find it disconcerting to have my plugin objects sitting around unused and unreaped, aka, memory leakage. To find out if this is a mod_perl probelm or not, try makiing your command line script call $tt-process twice in a row. If the object gets destroyed twice, this is mod_perl-related. Otherwise, it's a TT problem and officially [OT] for the mod_perl list. - Perrin
Re: object not being destroyed in a TemplateToolkit-based handler
"PH" == Perrin Harkins [EMAIL PROTECTED] writes: PH To find out if this is a mod_perl probelm or not, try makiing your command PH line script call $tt-process twice in a row. If the object gets PH destroyed twice, this is mod_perl-related. Otherwise, it's a TT PH problem and officially [OT] for the mod_perl list. Did. It is definitely only happening in mod_perl. On the command line, the object properly gets destroyed when expected, ie, before the print "end of template processing" happens.
Re: object not being destroyed in a TemplateToolkit-based handler
On Wed, 7 Feb 2001, Vivek Khera wrote: Did you (or anyone else) reproduce the non-destroy of my mini-plugin? I'd like to at least know if I'm doing something wrong in mod_perl. I find it disconcerting to have my plugin objects sitting around unused and unreaped, aka, memory leakage. Okay, I just tried the code you posted under mod_perl and it worked fine. I changed a couple of lines having to do with locations and package names, and I commented out the PRE_PROCESS/POST_PROCESS stuff. The plugin object reported being destroyed. - Perrin
object not being destroyed in a TemplateToolkit-based handler
I sent this to the Template Toolkit list but got no responses. I'm
pretty sure it is a mod_perl issue, but I can't for the life of me
figure out why the object doesn't get destroyed in the mod_perl
context. A standalone test program always destroys the object at the
expected time.
This bug happens even under httpd -X.
--original message--
I have a plugin I'm writing to access an Apache::Session::MySQL
object. What I do is create a hash that contains the fields
"_CONTEXT" pointing to the context, "verbose" being a debug flag, and
"_session" being a reference to the tied hash from
Apache::Session::MySQL. The constructor looks something like this:
my $self = { _CONTEXT = $context, verbose = 0 };
bless $self, $class;
# do the tie, error checks, etc.
$self-{_session} = \%session;
return $self;
Now I have a handler in mod_perl that runs *.mlm files through $tt,
which is a TT object that has pre/post process, plugin path, and some
global stash variables pre-defined.
This works fine from my templates:
[% USE s = session %]
[% s.stepsdone = s.stepsdone + 1 %]
Psteps done = [% s.stepsdone %]/P
However, at the end of the template processing, the object is not
destroyed; that is, the DESTROY() method is never called, and
therefore the tied hash never gets untied and Apache::Session::MySQL
doesn't get a chance to write the data back to the store.
But when I kill httpd, all the objects created are then destroyed
(my DESTROY() has a debug statement that gets printed) and the session
is saved to the database (albeit, all identical since each new object
read the original data rather than the updated values).
It matters not whether I [% PROCESS %] or [% INCLUDE %] the template
that instantiates this object.
I tried to isolate a case of this in its own program, but of course
the object was destroyed every time...
Any ideas on where to trace this down?
Re: object not being destroyed in a TemplateToolkit-based handler
Vivek Khera ([EMAIL PROTECTED]) said something to this effect on 02/06/2001: However, at the end of the template processing, the object is not destroyed; that is, the DESTROY() method is never called, and therefore the tied hash never gets untied and Apache::Session::MySQL doesn't get a chance to write the data back to the store. You aren't clear about the scope of $tt; it sounds like a package level global, if it's being destroyed when the children exit. How about creating a PerlCleanupHandler to explicit destroy $tt? (darren) -- Entropy isn't what it used to be.
Re: object not being destroyed in a TemplateToolkit-based handler
On Tue, 6 Feb 2001, Vivek Khera wrote: However, at the end of the template processing, the object is not destroyed; that is, the DESTROY() method is never called, and therefore the tied hash never gets untied and Apache::Session::MySQL doesn't get a chance to write the data back to the store. Hmmm... If I'm reading the code correctly, what's supposed to happen is that the stash (where your plugin instance lives) gets localized when you call $tt-process() and de-localized at the end, which should result in anything you added to it (with your USE s = session) getting DESTROY-ed. Maybe there's a bug in this process somewhere? Are you keeping a copy of the stash anywhere else? Are you doing something in your plugin's load() method that involves a reference to the session object? That could cause this kind of problem. Maybe you could post a bit more of your plugin code. To make sure your stash is getting cleared, try putting some other object into it (by passing it to process) and see if it gets destroyed. If it does, then there's something about the way your plugin is written that's causing the problem. If not, TT has a problem. - Perrin
Re: object not being destroyed in a TemplateToolkit-based handler
On Tue, 6 Feb 2001, darren chamberlain wrote: Vivek Khera ([EMAIL PROTECTED]) said something to this effect on 02/06/2001: However, at the end of the template processing, the object is not destroyed; that is, the DESTROY() method is never called, and therefore the tied hash never gets untied and Apache::Session::MySQL doesn't get a chance to write the data back to the store. You aren't clear about the scope of $tt; it sounds like a package level global, if it's being destroyed when the children exit. How about creating a PerlCleanupHandler to explicit destroy $tt? No, don't do that. You need $tt to stick around, so that you can get the large speed increase from using the in-memory cache. - Perrin
