On Wed, Sep 16, 2015 at 2:51 PM, Roberto De Ioris <[email protected]> wrote:
> > > On Wed, Sep 16, 2015 at 2:37 PM, Руслан Закиров <[email protected]> wrote: > > > >> Going to try 2.0.11 and report back > > > > > > still fails. > > > > EXTENDED INFO: > > uri: /test.html with args:$VAR1 = {}; > > > > > > Wed Sep 16 14:41:59 2015 - *** HARAKIRI ON WORKER 1 (pid: 15702, try: 1) > > *** > > Wed Sep 16 14:41:59 2015 - HARAKIRI: -- wchan> hrtimer_nanosleep > > Wed Sep 16 14:41:59 2015 - HARAKIRI !!! worker 1 status !!! > > Wed Sep 16 14:41:59 2015 - HARAKIRI [core 0] 127.0.0.1 - GET /test.html > > since 1442403715 > > Wed Sep 16 14:41:59 2015 - HARAKIRI !!! end of worker 1 status !!! > > Wed Sep 16 14:42:00 2015 - DAMN ! worker 1 (pid: 15702) died, killed by > > signal 9 :( trying respawn ... > > Wed Sep 16 14:42:00 2015 - Respawned uWSGI worker 1 (new pid: 15719) > > > > Sports INFO [Wed Sep 16 14:42:00 2015] (RU) pid: 15719 Begin request > > processing /test.html,%20/errors/502.html > > EXTENDED INFO: > > uri: /test.html,%20/errors/502.html with args:$VAR1 = {}; > > > > > > It looks like nginx is adding a second REQUEST_URI object (uWSGI is not > able to do it without internal routing rules) > > How do you manage the fallback in nginx ? In the above case it's error_document directive. In the case I started from two requests was not related to each other - just two request coming from different users happens to hit the same back-end. Can you report its configuration ? > As I was able to reproduce the problem in a test env. I want to try to reproduce it without nginx by hitting uwsgi port directly. -- Руслан Закиров Руководитель отдела разработки веб-сервисов +7(916) 597-92-69, ruz @ <http://www.sports.ru/>
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
