Roberto De Ioris <roberto@...> writes:
> Il giorno 06/apr/2011, alle ore 12.49, Pavel Kolla ha scritto:
>
> > Hello
> > I am using nginx/0.8.54 + uwsgi/0.9.6.6 + python/3.1
> > (SQLAlchemy/Postgres) to power my backend and once in a while i
> > encounter some issue (usually infrastructure related) which presents
> > itself as a uWSGI 502/nginx 500 error with very little info available
> > even in debug mode -
> >
> > pkolla:88 [pid: 32734|app: 0|req: 14/15] 192.168.1.160 (test) {66 vars
> > in 1150 bytes} [Wed Apr 6 13:07:55 2011] POST
> > /query/ListPersonsByLastnameLike?nocache=1302080877506 => generated 0
> > bytes in 1 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 async switches
> > on async core 0)
> >
> > How can I increase verbosity of these message to the level where i can
> > figure out root of the problem easily?
> > Current approach is relatively cumbersome and includes remote
> > debugging sessions, aggressive application level logging, netcat and
> > tshark...
> >
> >
>
> Do you use some WSGI adapter in your custom app (like werkzeug or similar) ?
>
> The only things that come to my mind is the exception_info usage (that has
been added
> only in 0.9.7.2) not being used in 0.9.6
>
> Can you check if your app/middleware make use of this argument ? (it is
passed as the third argument of start_response)
>
Will upgrade and see however as i kept digging - this request never makes to
python so it wont matter what backend does and can see (in terms of uwsgi
passed environment). I intentionally created situation where python raises
unhandled error which is trapped by generic logic if run w/o middleware, and
made a test cases where python borks on parse stage - for these both uwsgi
reported same 500 error and nothing extra was in the elog file.
Furthermore, debugging shows that in case if URI or POST-data contain non-ASCII
characters (cyrilic letters or some symbols) uWSGI produces same (at least it
looks same) error. Which leads me to believe there are some issues with unicode
handling in my setup, however i'm not quite sure where exactly..
More on original subject - my point was that information in the logfile is not
sufficient for debugging the issue (or any similar infrastrucure layer issues)
and w/o ability to increase verbosity it's quite time consuming to deal with
this kind of problems.
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
