Re: [AOLSERVER] tdom leak fix
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 $doc
} err]} {
ns_log error $err
}
$doc delete
You have to guarantee that the [$doc delete] happens--if an uncaught
Tcl error stops execution and the [$doc delete] doesn't happen, you
leak.
-- Dossy
--
Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] tdom leak fix
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 does this by setting a variable trace on the passed variable to call delete. The upside is that it gets automatically cleaned up no matter how the proc returns, whether by explicit return or by having an error thrown. The downside is that you cannot return the document thusly parsed from a proc, as the underlying object was cleaned up when the variable it was assigned to was unset. This is an unfortunate result of the tcl object model (that is, Tcl_Objs, not OOP) and is not likely to be fixed before tcl 9 (if at all). -J John Buckman wrote: 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 has to be explicitly deleted ). Therefore, I highly recommend adding a $doc delete to manually delete any tdom objects you create. Below are the relevant docs for tdom for this. -john dom parse ?options? ?data? Parses the XML information and builds up the DOM tree in memory providing a Tcl object command to this DOM document object. Example: dom parse $xml doc $doc documentElement root parses the XML in the variable xml, creates the DOM tree in memory, make a reference to the document object, visible in Tcl as a document object command, and assigns this new object name to the variable doc. When doc gets freed, the DOM tree and the associated Tcl command object (document and all node objects) are freed automatically. set document [dom parse $xml] set root [$document documentElement] parses the XML in the variable xml, creates the DOM tree in memory, make a reference to the document object, visible in Tcl as a document object command, and returns this new object name, which is then stored in document. To free the underlying DOM tree and the associative Tcl object commands (document + nodes + fragment nodes) the document object command has to be explicitly deleted by: $document delete or rename $document -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tdom leak fix
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,
setting up the above as a scheduled proc. Looking at my code I also
included
eval unset [info vars ::dom::_node*Attributes]
although I don't recall if this was for tdom or tclxml.
-J
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] tdom leak fix
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 them when your dealing
with them and explicitly delete them.
Thanks
Nick
Having run into this same problem before I did something similar,
setting up the above as a scheduled proc. Looking at my code I also
included
eval unset [info vars ::dom::_node*Attributes]
although I don't recall if this was for tdom or tclxml.
-J
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
Nathan Folkman
[EMAIL PROTECTED]
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] tdom leak fix
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 (dom object) issue was pretty much the same. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tdom leak fix
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. Configuration: ns_section ns/server/server1/adp ns_param startpage PATH/start.adp start.adp: % _ns_adp_include [ns_url2file [ns_conn url]] # # tDOM cleanup code goes here. # % On 2/28/07, Tom Jackson [EMAIL PROTECTED] wrote: Yes, wouldn't it be nice if ns_atclose worked in scheduled procs? In a conn you can use ns_atclose, but it has been removed from scheduled procs. Is there no way to run a trace on a scheduled proc? I have looked at ns_ictl, but it looks like the scheduling is per module, so you can't just activate it when you want like ns_atclose. Not having to catch code is a big benefit, being able to use the same code in all threads would be very nice. tom jackson On Wednesday 28 February 2007 11:41, Nathan Folkman wrote: Don't you open yourself up for a race condition if that code is in a scheduled proc? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- Nathan Folkman [EMAIL PROTECTED] -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tdom leak fix
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, 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 (dom object) issue was pretty much the same. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- Nathan Folkman [EMAIL PROTECTED] -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
