On 2006.09.02, John Buckman <[EMAIL PROTECTED]> wrote:
> Has anyone ever had any problems with nsdb slowly losing database
> handles, so that eventually "ns_db gethandle" never returns?
>
> I'm working with Vlad to track down that kind of problem, that we're
> assuming is in his BerkeleyDB/nsdb driver, but I thought I'd ask if
> anyone's had that problem with other drivers.
Are you using ns_markfordelete to cycle interps? The nsdb handle
auto-cleanup uses the Ns_TclRegisterDeferred() mechanism, which gets
triggered via "ns_ictl cleanup" which gets called from "ns_cleanup".
Perhaps implementing "ns_db cleanup" which releases all currently held
handles ... and then calling that from "ns_cleanup" along with all the
other cleanup ... would be better.
Hold on a second ... Ns_TclDeAllocateInterp() changed significantly
between 4.0 and 4.5 ... I can't actually find where in 4.5 the
ns_cleanup gets called ... ahh, it got moved to nsd/init.tcl, using:
#
# Register the init and cleanup callbacks.
#
ns_ictl trace create {ns_ictl update}
ns_ictl trace allocate ns_init
ns_ictl trace deallocate ns_cleanup
> If I manually "ns_db releasehandle" after every handle usage, I have
> no problems (but the app is slower), it's only when I rely on the
> auto-cleanup of handles when the ADP page closes that there's a problem.
Hmm ... the app is slower if you explicitly perform "ns_db
releasehandle"? Generally, "ns_db releasehandle" should be *very* fast,
as all you're doing is pushing the handle back into the pool. If it's
"slow" then I'd look at the DB driver to see what it's actually doing
when you release a handle (it may be doing a cancel/flush).
But, yes, this makes total sense: if "ns_db releasehandle" isn't "fast"
and you do it "asynchronously" by letting it happen in your interp
cleanup phase ... then it's very possible to end up in a state where new
requests will block/timeout on getting a new handle, as all of your
available handles are still held by previous requests that still have
not cleaned up yet.
In theory, you could avoid this by ensuring that maxthreads and db
connection limit are equal. Unless, you're leaking handles in a
non-connection thread that allocates but doesn't explicitly release
handles.
-- 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.
