On 2 April 2017 at 12:00, Gustaf Neumann <neum...@wu.ac.at> 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
+ }
+
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
