Hi Roberto,
I tried with processes: 4 and threads: 0 and the outcome is the same.
I forgot to mention this in the previous message but uWSGI consistently
logs only the first 3 requests to /proxy despite the fact that 22
(successful) requests are made as a result of the request to
/proxy/jupyter/ipython/tree. No other requests are logged until the
"timeout" period expires. With UWSGI_DEBUG set and times added to the
offload session debug messages you can see a bit more:
Here's the 3rd request to /proxy, the last one logged:
[uWSGI DEBUG] called 0x7f268a856b90 0x7f265d916c68 1
Proxy localhost:8192 to 172.17.0.1:32780
[offload] created session 0x7ffd81de4ea0 at 1539962620
[pid: 7942|app: -1|req: -1/20] 127.0.0.1 () {46 vars in 1144 bytes} [Fri
Oct 19 11:23:40 2018] GET
/proxy/jupyter/ipython/api/terminals?_=1539962620828 => generated 0 bytes
in 2 msecs via offload() (HTTP/1.1 202) 0 headers in 0 bytes (0 switches on
core 0)
60 seconds later, 3 sessions are destroyed:
[offload] destroyed session 0x7f2658000bd0 at 1539962680
[offload] destroyed session 0x7f2658000bd0 at 1539962680
[offload] destroyed session 0x7f2658000bd0 at 1539962680
It's not until all 3 are destroyed that requests to / work properly again.
This is the case regardless of the number of processes, threads, or offload
threads.
--nate
On Fri, Oct 19, 2018 at 7:49 AM Roberto De Ioris <robe...@unbit.it> wrote:
>
> > Hi all,
> >
> > My application has the ability to launch per-client Jupyter Notebooks in
> > Docker containers and maintains a mapping from the client's session
> > (cookie) to their Jupyter container's port. It then starts up a proxy
> > application written in Node.js to allow clients to access their
> > containers.
> > The proxy application listens on its own port, although in production
> > deployments, both uWSGI and the proxy are proxied by nginx, which serves
> > the application at / and the proxy at /proxy on a single port.
> >
> > I am trying to replicate this behavior purely in a single instance of
> > uWSGI
> > (without emperor) and currently everything works, except that when you
> > access Jupyter via /proxy, requests to paths outside of /proxy are also
> > proxied to Jupyter (instead of sent to the application). Only requests
> > with
> > the session cookie that accessed /proxy see this behavior, other clients
> > continue to be able to access the application as usual. After around a
> > minute of not making requests to /proxy, everything returns to normal and
> > requests outside /proxy are again delivered to the application.
> >
> > The key seems to be the use of offload-threads: if enabled (any number),
> > this behavior occurs. If not enabled, the proxy works, albeit very
> slowly,
> > and requests to paths outside /proxy continue to be delivered to the
> > application as intended.
> >
> > My configuration is here:
> > https://gist.github.com/natefoo/be55129d68517d80681a5038f048c926
> >
> > In summary:
> >
> > Application at /
> > Proxy at /proxy
> >
> > 1. Client requests /, request is handled by application
> > 2. Client launches Jupyter Notebook via application and requests
> > /proxy/jupyter/ipython/tree, request is proxied to Jupyter
> > 3. Client requests /, request is proxied to Jupyter
> > 4. Client requests / again after waiting ~1 minute, request is handled by
> > application
> >
> > T
>
> Hi, can you try disabling multithreading (threads: 0) and instead using
> multiprocessing ? (processes: 4)
>
> Thanks
> --
> Roberto De Ioris
> http://unbit.com
> _______________________________________________
> uWSGI mailing list
> uWSGI@lists.unbit.it
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
_______________________________________________
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
