On 22 February 2017 at 13:49, Gustaf Neumann <neum...@wu.ac.at> wrote:
> 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?
>
Yes
> - is the connection to the backend via https?
>
Yes
> - how do the https driver configurations differ?
>
The only difference as I recall is they listen on different ports with a
different backend destinations, but otherwise identical.
For example:
ns_section "ns/server/proxy_www/modules"
ns_param nsssl1 nsssl.so
ns_section "ns/server/proxy_erp/modules"
ns_param nsssl2 nsssl.so
ns_section "ns/server/proxy_www/module/nsssl1"
ns_param port $https_port
ns_param address $address
ns_param hostname $hostname
...
ns_section "ns/server/proxy_erp/module/nsssl2"
ns_param port $https_erp_port
ns_param address $address
ns_param hostname $hostname
...
I jumped to the conclusion regarding the driver threads by examining the
output of "ns_connchan list" at the point the ns_connchan callbacks are
defined.
I'll see if I can put together a simple test case using the revproxy module.
But in our environment, the case that works, both channels are listed as
nsssl1:
- Request received for server *proxy_www*
- The backend and frontend channels are set up:
- back *conn2 *front conn3 method GET version 1.0
https://localhost:8001/index.html <https://localhost:8001/index.html>
- "ns_connchan list" shows:
- *conn2 *{} 1487772742.608164 *nsssl1 *874 0 {}
- conn3 {} 1487772742.604384 *nsssl1 *172.31.100.23 0 0 {}
- The backendReply callback is registered against backend *conn2*.
- backendReply is called when the socket becomes READABLE
- *conn2 *is read... etc etc
The case that doesn't work, the new backend channel is listed as nsssl1
where-as this connection thread is servicing a nsssl2 request.
- Request received for server *proxy_erp*
- The backend and frontend channels are set up:
- back *conn4 *front conn5 method GET version 1.0
https://localhost:8002/index.html <https://localhost:8002/index.html>
- "ns_connchan list" shows (differing driver modules)
- *conn4 *{} 1487772797.297281 *nsssl1 *625 0 {}
- conn0 -socks- 1487767354.759715 nsssl1 625 0 {}
- conn5 {} 1487772797.293823 *nsssl2 *172.31.100.23 0 0 {}
- The backendReply callback is registered against backend *conn4*.
- backendReply is called when *conn4* becomes READABLE
- Then error saying *conn4* does not exist
------------------------------------------------------------------------------
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
