Re: [AOLSERVER] Null responses

[Peter S. <f_p...@ho...>]

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: cy...@ru...
To: aol...@li...
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
aol...@li...
https://lists.sourceforge.net/lists/listinfo/aolserver-talk