Hi Roberto,
Any ideas on where to go from here? I'm really hoping it'll be possible to
get this working as it'll be a much simpler configuration to ship for
downstream deployers of our application than emperor.
--nate
On Fri, Oct 19, 2018 at 11:37 AM Nate Coraor <n...@bx.psu.edu> wrote:
> 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
