Re: [naviserver-devel] revproxy timeouts

[David O. <da...@qc...>]

On 2 April 2017 at 12:00, Gustaf Neumann <ne...@wu...> wrote:

> Just to be sure: timeouts during connection creation work fine, but read
> timeouts from the back-end lead to the problem. ... and this happened with
> an https backend. And you are experiencing this under Linux. Did i
> understand this correctly?
>

I haven't tested connection creation timeouts. Only the situation where the
backend accepts the connection but takes a long time to respond.
(My testcase is a backend URL which just does "ns_sleep 100000")
It is an https backend. Running naviserver 4.99.16d4. Debian 8.6 with
kernel 3.16.39-1+deb8u2.



>
> actually, ns_connchan has no own timeout semantics, but relies on the
> Ns_SockCallback* infrastructure. In general, the Tcl callback can signal
> with a result "0", that the current connection channel should be closed
> automatically.
>

Yes, I though the following would be sufficient to clean up on receiving a
timeout:

+    nsf::proc backendReply { from to url timeout arg when } {
+
+        if { $when eq "t" } {
+            if { [ns_connchan exists $to] } {
+                # Return a 504 to $to conn at this point
+                ns_connchan close $to
+            }
+            return 0
+        }
+