This had a knock-on effect meaning the timeout stopped functioning for me.
The order change is changing which callback is timing out first and
backendReply
was triggered. It doesn't deal with the timeout properly, it just
immediately starts trying to read from the backend chan.
So adding timeout handling to backendReply like the following worked:
https://bitbucket.org/davidqc/revproxy/branches/compare/davidqc/revproxy:tip%0Dnaviserver/revproxy:tip#diff
Another option which worked was removing the timeout from the
backendReply callback
completely and deal with it all from within spool.
On 10 April 2017 at 14:29, David Osborne <da...@qcode.co.uk> wrote:
> Hi,
>
> While testing the revproxy code I coming across the occasional error like
> the following:
>
> connchan "conn237" does not exist
> while executing
> "ns_connchan callback -timeout $timeout $frontendChan [list spool
> $frontendChan $backendChan client $timeout 0 ] rex"
>
> Seems like sometimes the callback on the $backendChan can be created,
> triggered, and autoclose the $frontendChan before the callback creation
> on the $frontendChan is even created.
>
> This is not an error that affects the user since the request has been
> dealt with fully but the proxy code throws errors.
>
> I found swapping the two ns_connchan callback statements solves this eg.
> https://bitbucket.org/davidqc/revproxy/commits/
> 93180d1a66c82f3e87a39b69e4cbd25c9926c1f3
>
> --
> 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
