Provide me with the logging from a period before the restart until a period after.
The log can be very informative if you know what to look for. Graham On 15/02/2015, at 6:43 PM, Paul Royik <[email protected]> wrote: > I actually have custom error 500 page. This means, that when Django throws > error, custom page should be shown. > But it is not the case. Standard white-background apache page is shown. > So, I think that problem is not in Django exception. Otherwise Django would > show custom page, which is not the case. > In logs I saw only that server was restarted. > Can I somehow tune logging, so that real error is written? > > On Sunday, February 15, 2015 at 2:44:50 AM UTC+2, Graham Dumpleton wrote: > > On 15/02/2015, at 10:53 AM, Paul Royik <[email protected]> wrote: > > > I already tried this approach. > > > > It seems good. > > But when I tested it on server, by simultaneously executing page on two > > different computers, it gave me 500 error. > > > > How this can be explained? Again something with apache? Logs didn't show > > anything. But I noticed again serious memory usage. And this happens only > > when I use code for limiting time. > > > Some tips for you about ensuring you get the best help. > > Stop discarding the message content for the message you are replying to. It > can be frustrating to have to keep going back to old messages to see what was > said originally and what you may be following up to, especially when on a > phone. When asking questions on mailing list, let the person you are asking > questions of decide what can be discarded from the message chain as they will > know better what should be kept in the message to provide easy access to > important information for context. > > When you reply to say you are have a new error, provide the actual code you > were using exactly at the time you had the error. Saves the person who is > helping you having to go back and ask for it if it is unclear what code you > were using. > > Your messages here and on StackOverflow show that you play around with the > example code I am giving you and I have reduced confidence you were running > with the code I suggested at the time of the problem you are now relating to. > > If you are getting 500 errors and nothing is being logged, it is because > Django is capturing the exception and converting it to a generic 500 error > response page. Configure Django to send you emails with the details of the > exceptions. If you are on a local system, then set DEBUG=True in the Django > settings so the details of the error are shown in response that goes back to > the browser. > > As to the code, I did test it this time, including under mod_wsgi with 20 > request threads and hitting it with concurrent and successive requests with a > benchmarking tool. I saw no issues and it appeared to behave as I would > expect. > > So in a test2.py file I had: > > import time > import functools > import threading > > def time_limit(seconds): > def decorator(func): > func.info = threading.local() > def check_timeout(): > if time.time() > func.info.end_time: > raise RuntimeError('timeout') > > func.check_timeout = check_timeout > > @functools.wraps(func) > def wrapper(*args, **kwargs): > print 'hasattr counter', hasattr(func.info, 'counter') > if not hasattr(func.info, 'counter'): > print 'init counter to 0' > func.info.counter = 0 > if func.info.counter == 0: > func.info.end_time = time.time() + seconds > print 'counter', func.info.counter > func.info.counter += 1 > try: > return func(*args, **kwargs) > finally: > func.info.counter -= 1 > > return wrapper > > return decorator > > @time_limit(5) > def algorithm(limit, nest=0): > algorithm.check_timeout() > print 'sleep' > time.sleep(1.0) > if nest == limit: > print 'return' > return > algorithm(limit, nest+1) > > In serial2.py I had a straight serialised test: > > from test2 import algorithm > > try: > algorithm(3) > except RuntimeError: > print 'timeout' > > try: > algorithm(10) > except RuntimeError: > print 'timeout' > > try: > algorithm(10) > except RuntimeError: > print 'timeout' > > And then in hello2.wsgi I had it used by a WSGI application. > > from test2 import algorithm > > def application(environ, start_response): > status = '200 OK' > output = b'Hello World!' > > algorithm(1) > > response_headers = [('Content-type', 'text/plain'), > ('Content-Length', str(len(output)))] > start_response(status, response_headers) > > return [output] > > In the latter case I ran mod_wsgi-express against it as: > > mod_wsgi-express start-server hello2.wsgi --port 8002 --threads=20 > > and then hit it with ab as: > > ab -n 100 -c 15 http://localhost:8002/ > > In this case it wasn't designed to timeout anything, but that should not be a > concern as the counter initialisation is still being tested. > > Do note that if you did cut and paste that last code, I did change the > exception type. > > Anyway, the best thing to do is setup Django so that it provides the details > of the exception it captured but then effectively discarded because it > converted it to a 500 page. > > Graham > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
