g the same problem with a graceful-stop. It may be the nature
of the code that I'm using, which does the following:
To do a search:
---
- check for the search in the cache
- if result == $LOCK then go back to previous step
- if no result
- store $LOCK in cache
- l
Hi all
I'm finding that DESTROY blocks on objects stored in lexical variables
are not being called on apachectl stop / restart.
These lexicals are destroyed as they should be when they go out of
scope.
I've resorted to storing weak refs to these objects in a hash and
cleaning them
Good call, thanks for the help guys. I really appreciate it.
Jordan
On 10/11/06, Philip M. Gollucci <[EMAIL PROTECTED]> wrote:
Dondi M. Stroma wrote:
> I believe that since $db is a global variable it's not going to be
> destroyed. If you got rid of the 'use vars' and changed it to
>
> sub ha
Dondi M. Stroma wrote:
I believe that since $db is a global variable it's not going to be
destroyed. If you got rid of the 'use vars' and changed it to
sub handler {
my $r = shift;
my $db = eCarList::DB->new();
...
}
then it would be.
This is absolutely the correct change.
--
---
uot; <[EMAIL PROTECTED]>
To:
Sent: Wednesday, October 11, 2006 12:06 PM
Subject: Re: Re: DESTROY
I have the call to the module in a block already.
It goes something like:
package eCarList::Admin;
use eCarList::DB;
use eCarList::Output;
use vars qw($db);
sub handler {
my $r = sh
ote:
Try wrapping your calls to your module in a function because an object
is cleaned up at the end of a block.
-- yourscript.pl --
sub main()
{
my $db = Apache::DBI->new();
} # at the end the object refrenced by $apache_dbi will have it's
destroy method called
I think you have ha
I actually did something like that, but when I did, the browser would
return the html, the http headers and all to the browser so that the
page would not be rendered. Instead of the string that I tried to
output in the destroy method, I would get '0' after the .
On 10/10/06, Dondi
If I were you, I would put something like
warn "I'm being destroyed.";
in the DESTROY method, so you'll know for sure whether that is the case.
- Original Message -
From: "Jordan McLain" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, October 10, 2006 1
That is not the problem... The problem comes in when I do not use
Apache::DBI and I still end up with alot of mysql threads. The
problem is that I do not think DESTROY is being called.
On 10/10/06, Jordan McLain <[EMAIL PROTECTED]> wrote:
That is not the problem... The problem comes i
>
>I am not sure, but I think the problem you have is that Apache::DBI ignores
>any disconnect() calls on database handles, and doesn't actually disconnect.
That's true.Apache::DBI ignores all the disconnect() calls.
--
Jeff Pang
NetEase AntiSpam Team
http://corp.netease.com
I am not sure, but I think the problem you have is that Apache::DBI ignores
any disconnect() calls on database handles, and doesn't actually disconnect.
- Original Message -
From: "Jordan McLain" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, October 10, 2006 10:57 PM
disconnects
in the DESTROY method for the module(all of my database interaction is
abstracted using an OO module) and I end up having no difference
between Apache::DBI and using only DBI (threads stay persistent)
unless I call destroy explicitly from the handler ( $db->DESTROY ).
sub DESTROY {
n too, I just want to see if I can
> > see the home page under debugging mode, but I can't
>
> Your browser never gets anything back? Try using telnet or lwp-get to
> test it, so you can see if anything gets sent back. You don't need to
> test the images.
>
>
can't, only lots of
IO::Handle::DESTROY, and finally, hang there,
I can't input any more debugger command, kill the apache2 process is
the only thing left could be done.
And on the browser side, I see from the status bar it is still waiting
to dowload the .gif images, however, if trun
Ken Perl wrote:
I tried to stop apache by issuing apache2ctl -k stop in another
terminal, the command exit without any output, but the debugger is
still hung there. I have to send signal KILL to the process.
That will work, but the usual way to stop is to hit Ctrl-C in the
debugger terminal.
gt; Ken Perl <[EMAIL PROTECTED]> wrote:
>
> > And I also can't quit Apache::DB by entering many 'q' commands,
> > DB<5> q
> > IO::Handle::DESTROY(/usr/lib/perl/5.8/IO/Handle.pm:75):
> > 75: sub DESTROY {}
> > DB<5> q
>
And I also can't quit Apache::DB by entering many 'q' commands,
DB<5> q
IO::Handle::DESTROY(/usr/lib/perl/5.8/IO/Handle.pm:75):
75: sub DESTROY {}
DB<5> q
IO::Handle::DESTROY(/usr/lib/perl/5.8/IO/Handle.pm:75):
75: sub DESTROY {}
DB<5> q
IO::Han
;1> r
void context return from IO::Handle::DESTROY
IO::Handle::DESTROY(/usr/lib/perl/5.8/IO/Handle.pm:75):
75: sub DESTROY {}
DB<1> r
void context return from IO::Handle::DESTROY
Apache2::SizeLimit::handler(/usr/lib/perl5/Apache2/SizeLimit.pm:248):
248:my $r = shift;
Anybody kn
alias of destroy to DESTROY.
I've implemented it and all the filters went broken. The reason is that
the $bb argument passed to the input filters is special [1], the caller
expects the callee to fill it in. With implicit DESTROY it gets
destroyed before the caller gets it, wrecking havoc. So
dorian wrote:
the point brought up at the talk today regarding the explicit destroy
method of APR::Brigade, rather than an implicit DESTROY method. as
we discussed, it would be significantly more perlish to provide an
implicit dereference in DESTROY. it shouldn't be too hard to
implement. i
the point brought up at the talk today regarding the explicit destroy
method of APR::Brigade, rather than an implicit DESTROY method. as
we discussed, it would be significantly more perlish to provide an
implicit dereference in DESTROY. it shouldn't be too hard to
implement. if you want a
lRun__a_closer_look
>
Thank you very much William. I think you just cleaned my windows and now
I can look outside and see that it is actually raining ;)[1]. At first I
thought I was going nuts, couldn't imagine Perl to not destroy my
objects. But now I see that this is actually happening.
A
> William
> >
> > [1]
>
http://perl.apache.org/docs/1.0/guide/porting.html#Apache__PerlRun__a_closer_look
> >
>
> Thank you very much William. I think you just cleaned my windows and now
> I can look outside and see that it is actually raining ;)[1]. At first I
&g
On Sat, Jul 10, 2004 at 11:33:44AM +0200, [EMAIL PROTECTED] wrote:
> Oops, think I should have told ya something more on why I think DESTROY is not
> handled. Well, that's very easy to say: The lines printed to STDERR from within
> the DESTROY function do not appear in my error_lo
Quoting [EMAIL PROTECTED]:
> Hi Fella's,
>
(..)
>
>
Oops, think I should have told ya something more on why I think DESTROY is not
handled. Well, that's very easy to say: The lines printed to STDERR from within
the DESTROY function do not appear in my error_log. Though th
bless {Link => $rec}, $pkg;
7 return $pkg;
8 }
9 sub DESTROY {
10 print STDERR ref(shift)."::DESTROY()\n";
11 }
12 1;
// - TestTop.pm
1 package TestTop;
2
3 use strict;
4 use Test;
5
6 sub new {
7 m
26 matches
Mail list logo
