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?
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.
-g
Am 31.03.17 um 16:47 schrieb David Osborne:
Hi,
I've been trying to get revproxy to work with a timeout. So if the
backend doesn't reply within $timeout secs, then the connection is closed.
What I thought we could do was set a timeout when creating the
callback to call backendReply.
Then when the callback is triggered with $when eq "t" we could return
a 504 then close the connection.
This is an outline if what I am trying:
https://bitbucket.org/davidqc/revproxy/commits/658704673bcb07d27962a9b4d4a89a07a64c5843
This appears to work initally. When accessing a backend page which
takes over 10 seconds to respond, the client gets a 504.
But it appears that things aren't cleaned up properly and the 2 socket
callbacks persist after the timeout.
Inline images 2
This has the effect that the proxy is essentially unresponsive and
doesn't forward any more requests (even the Control Ports are not
accessible locally).
If I restart the backend server, that brings the proxy back to life.
The proxy and the backend are running on different ports on the same
server in this case.
Should this approach work or have I misunderstood how ns_connchan
timeouts should work?
Thanks,
--
David
------------------------------------------------------------------------------
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
