Re: [naviserver-devel] revproxy

[Gustaf N. <ne...@wu...>]

Am 22.02.17 um 13:48 schrieb David Osborne:
> Short question:
> Is there a way to influence which driver thread "ns_connchan open" 
> will use?
... no, since ns_connchan does not use the driver threads, and when in 
the revproxy code issues the connection to the backend it is already in 
a connection thread (where the filter is running). After the setup in 
the connection thread, the callback execution happens in a "socks" thread.

However, opening connections uses the driver's setup information 
(certificate, ciphers, etc),  but only, when doing "ns_connchan open 
https://...". The connchan handles "conn0" ... are per-server, not 
per-driver, so it looks to me, as if in your case, the "conn0" was 
already closed.

Some questions:
- do you have multiple servers defined in one nsd?
- is the connection to the backend via https?
- how do the https driver configurations differ?

For debugging:
- the revproxy code has a variable "verbose". When set to 1, it gives 
more details.
- even more details can be obtained via "ns_logctl severity 
Debug(ns:driver) on"
   (e.g. add this to the end of your startup file)

all the best
-gn

>
> Longer question:
> We have 2 driver threads listening on different ports, nsssl1 & nsssl2.
> Using backenReply/spool works ok for GET requests which come in on 
> driver nsssl1 (we have issues with POSTs working but I've not looked 
> at that yet).
>
> But if the request comes in on driver nsssl2, when we "ns_connchan 
> open" to our backend, the channel is on nsssl1, so then when the 
> backendReply callback is triggered it tries to read the handle and 
> can't find it.
>
> eg:
> [22/Feb/2017:12:42:34][6739.7f6113fff700][-socks-] Error: connchan 
> "conn0" does not exist
> connchan "conn0" does not exist
>     while executing
> "ns_connchan read $from"
>     (procedure "backendReply" line 6)
>     invoked from within
> "backendReply conn0 conn1 https://localhost:8002/login_form.html 0 r"
> (context: connchan proc)
>
> What would be the best way to avoid this issue?
>
> Thanks,
> --