Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#268 ns_adp_parse returns empty string

aolserver_v40
open
7
2006-03-13
2006-03-13
GregM
No

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.

Discussion

  • GregM
    GregM
    2006-03-13

    • priority: 5 --> 7
    • assigned_to: nobody --> dossy
     
  • Dossy Shiobara
    Dossy Shiobara
    2006-03-13

    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
    GregM
    2006-03-13

    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
    GregM
    2006-07-13

    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.