Not sure if this will help, but....
If you have a preauth filter (possibly other filters too) which does an
ns_adp_abort (and/or possibly ns_adp_break) within the filter or within a proc
called from the filter then the next time that thread is used, the state will
be "abort" and will end the connection.
You can put this line as the first lines of your pre_auth filter:
ns_adp_exception statens_log notice $state
If you find states of "abort" in your log, do this as a simple hack to reset
the state:
ns_adp_exception stateif {$state=="abort" || $state=="break"} { catch
{ns_adp_return} set foobar [ns_adp_parse "Hello"]}
It may be a place to start looking, but if you have a ns_log in your preauth
which is not logging then I would guess the issue is somewhat different. But
anyone who may use an ns_adp_abort or ns_adp_break from within a filter should
be aware of this. I believe using ns_adp_abort in a filter before version 4
worked fine, since 4.0 or 4.5 it causes this abort state issue, I don't
remember exactly, it was a long time ago that I had upgraded and had to figure
that out.
_Peter
Date: Tue, 26 Aug 2014 18:05:31 +0200
From: c...@rubylane.com
To: aolserver-talk@lists.sourceforge.net
Subject: [AOLSERVER] Null responses
Hi
I'm hoping there are still some subscribers to this list ;)
I'm trying to debug a strange condition we're seeing on a small percentage of
our connections: connections are being closed by the server without any
response being sent back on the connection (verified by looking at network
packet traces and inserting a logging transparent proxy between the client and
server). The network packet pattern we see is:
<normal TCP setup - SYN, SYN/ACK, ACK>
Request data (in a single frame, or multiple), ACK
Then the connection is closed by the server after 10 - 70 ms, without any data
being sent, with a FIN/ACK (still getting confirmation on this - these logs are
from the other side of the man-in-the-middle proxy I'm using to get debugging
info).
For some of the failed requests, the server processing never gets as far as the
start of our Tcl code (a preauth filter that starts with an ns_log that doesn't
show up in the server log).
For others the request is processed normally and an access.log message written
indicating that a response was generated with HTTP code 200, but no packet
shows up on the network.
There is no pattern to the failed requests (sometimes requests for favicon.ico
fail), and retrying the exact request shortly afterwards often succeeds.
Has anyone seen anything like this before, or have any advice on how to narrow
down the cause further?
We're running a slightly patched version of the last 4.5.2 rc, on Ubuntu
12.04.5 64bit on Amazon EC2 instances, with Tcl 8.6.1
Thanks
Cyan
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk
