> "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 t
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
> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
PH> On Thu, 8 Feb 2001, 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.
PH> Well, that is odd sinc
> "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 de
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
> "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 offic
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
> "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 someo
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
> "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> anythi
> "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
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 ge
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 st
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 c
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 happ
15 matches
Mail list logo