#268 ns_adp_parse returns empty string

[GregM]

On our web server, running version 4.0.10, we have 25
threads running with no thread die-off. Occasionally,
we've noticed HTTP 200s being returned with a
Content-Length of 0. We've tracked this down to
ns_adp_parse returning null in our application. We're
calling this function like:

set parsed_code [ns_adp_parse -string $adp_to_parse]

and parsed_code comes back as "" for the affected thread.

This seems to affect all ns_adp_parse calls for an
affected thread (interpreter?) -- generally we see it
on only one of the 25 threads, but all HTTP requests
for an ADP page for that thread return no content. Tcl
requests work fine.

Here's some info from our config:

ns_section ns/server/${server}
ns_param PageRoot ${server_root}/www
ns_param DirectoryFile {index.tcl,index.adp}
ns_param MinThreads 25
ns_param MaxThreads 25
ns_param MaxConnections 250
ns_param MaxDropped 0
ns_param MaxKeepAlive 100
ns_param KeepAliveTimeout 10
ns_param SockTimeout 15
ns_param ThreadTimeout 3600
ns_param ConnsPerThread 0
ns_param CheckModifiedSince false
ns_param EnableTclPages off

ns_section ns/server/${server}/adp
ns_param Cache on
ns_param Map /*.adp
ns_param DefaultParser fancy
ns_param EnableExpire false
ns_param EnableDebug false

We're running on Linux 2.4.25 (Debian Woody), on an SMP
Intel machine with 4 GB of RAM, and are using a heavily
modified version of ACS to serve our content.

Please let me know what other information would be
helpful, and how to trace this issue into Aolserver.
Since the problem only occurs on only one or two
threads at a time, and after the web server has seen
several hundred thousand requests, it's somewhat
difficult to reproduce.

[Dossy Shiobara]

Logged In: YES
user_id=21885

Is there anything being written to the server log
(especially errors) at the time the ns_adp_parse returns the
empty string?

I'm suspicious that this is just an uncaught Tcl error
happening in the string being parsed by ns_adp_parse causing
it to return an empty string.

Also, to rule out the "obvious" -- when you get the empty
string back, are you also logging what was passed in via
$adp_to_parse? I mean, if your problem is upstream from the
ns_adp_parse -- i.e, whatever code is supposed to build up
the $adp_to_parse (is it coming out of a DB? if so, did the
DB query fail, thus returning empty string upstream?) ...
you have to make sure it's not passing in an empty string to
ns_adp_parse, because naturally you'll get an empty string
back out. :-)

[GregM]

Logged In: YES
user_id=1475175

No, the unfortunate part about this issue is that the server
log contains no info about the error.

I did try to rule out the obvious, though I could well have
missed something! Here's a "normal" thread call to
ns_adp_parse:

[13/Mar/2006:13:57:12][9679.19476][-conn:server::16]
Warning: adp_to_parse is length 4420 for /web/www/sample.adp
[13/Mar/2006:13:57:12][9679.19476][-conn:server::16]
Warning: parsed_code is length 237 for /web/www/sample.adp

The "affected" thread (does not matter what adp we try to
compile):

[13/Mar/2006:13:57:09][9679.25626][-conn:server::23]
Warning: adp_to_parse is length 4420 for /web/www/sample.adp
[13/Mar/2006:13:57:09][9679.25626][-conn:server::23]
Warning: parsed_code is length 0 for /web/www/sample.adp

This only starts to happen after 100,000+ requests (it feels
pretty random). Thanks for the help!

[GregM]

Logged In: YES
user_id=1475175

Sorry it took so long to get back to this. We increased our
stack size and the problem went away. I don't know enough
about the internals of the ADP parser to understand why no
error was thrown, but the larger stack seems to have fixed
the issue.