From: David O. <da...@qc...> - 2017-04-10 15:58:37
|
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...@qc...> 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 > |