FYI, on the tdom leak, I found that my app (BookMooch) was leaking as
well (thanks for mentioning the leak problem you're having, it helped
me find mine), and the reason is that tdom NEVER automatically
releases memory for the documents it creates (the docs say the
document object command
On 2007.02.28, John Buckman [EMAIL PROTECTED] wrote:
Therefore, I highly recommend adding a
$doc delete
to manually delete any tdom objects you create.
At AOL, the idiomatic code for handling tDOM often looks like this:
set doc [dom parse $xml]
if {[catch {
# ... do stuff with
Tom,
I really appreciate your help with this.
Here is my solution. It seems to work so far.
I altered the code in rewriteurl.tcl to the following:
ns_log Notice tcl/rewriteurl.tcl: loading test rewrite filters...
proc rewriteRequest { why } {
set url [ns_conn url]
Thorpe,
First question is how many virtual hosts? Second is how busy?
The simple virtual server was an example of a no-configuration virtual server.
It relies entirely on correctly setup DNS. I have written several other
virtual servers (tclvhr and vat) which have slightly different features,
tdom can do automatic deleting, but it has some strict limitations.
If you pass a variable name to dom parse, as in
dom parse $xml doc
foreach n [$doc selectNodes ...] ...
then the dom object will automatically get cleaned up when the variable
doc is unset, as on return from a proc. It
Nick Miller wrote:
Heya,
I have added:
foreach lostdom [info commands domDoc0*] {
$lostdom delete
}
As you say though, best to make sure you catch them when your dealing
with them and explicitly delete them.
Thanks
Nick
Having run into this same problem before I did something similar,
Don't you open yourself up for a race condition if that code is in a
scheduled proc?
On 2/28/07, Jeff Rogers [EMAIL PROTECTED] wrote:
Nick Miller wrote:
Heya,
I have added:
foreach lostdom [info commands domDoc0*] {
$lostdom delete
}
As you say though, best to make sure you catch
Nathan Folkman wrote:
Don't you open yourself up for a race condition if that code is in a
scheduled proc?
If it was an aolserver scheduled proc then yes, but in my application it
was running in an after rescheduling loop within tclhttpd so there was
no risk of pre-emption; but the memory
I believe ns_ictl is what you would want - ns_ictl oncleanup I believe.
Another option is to run all request through a configured start page and
to put the cleanup code in that .adp page. Nice thing about that approach is
that you can make changes without having to restart the server.
Cool.
BTW, I wouldn't call this a leak, and would instead call it misuse of tDOM.
;-)
On 2/28/07, Jeff Rogers [EMAIL PROTECTED] wrote:
Nathan Folkman wrote:
Don't you open yourself up for a race condition if that code is in a
scheduled proc?
If it was an aolserver scheduled proc then yes,
10 matches
Mail list logo
