Hi Wade, If this is something you can't reproduce in testing, and print statements are causing a problem in production, don't use them -- use logging instead. Django's logging tools, which build on Python's built-in logging libraries, are designed specifically for this sort of thing.
[1] https://docs.djangoproject.com/en/dev/topics/logging/ Yours, Russ On Thu, Dec 20, 2012 at 10:31 AM, Wade Williams <[email protected]>wrote: > Thanks, Russ. > > I guess i'm a little perplexed as to how exactly to debug this -- the > apache log shows no errors, and trying to debug with print statements just > forces the code to die due to a WSGI I/O Error. Any help that anyone can > provide on debugging is much appreciated; Thanks so much for your time. > > -\/\/ > > On Wednesday, December 19, 2012 7:09:41 PM UTC-7, Russell Keith-Magee > wrote: > >> >> >> On Thu, Dec 20, 2012 at 9:25 AM, Wade Williams >> <[email protected]>wrote: >> >>> Thanks Russ. I too thought it might be the loop to allocate a new >>> session key, but after studying the code and trying some forced debugs >>> (print x) I thought it could be due to the super __init__ spinning when it >>> couldnt find the session key in the db. I can access and insert into the DB >>> table during the lock, and the lock never seems to end (I've run it for >>> atleast an hour with no stop). We've built out our stuff exclusively on 1.5 >>> so shouldnt be any 1.4 migration issues. Here is the session middleware: >>> >>> >> To be clear - it's wasn't so much migration issues I was worried about >> -- it was whether we've introduced a regression into Django core. Your >> original question was "is this a 1.5 bug?", which suggested to me that >> you've seen your code work on older version of Django. If that's not the >> case, then it seems that you're reporting "my custom session middleware >> doesn't work". While this is certainly a problem (for you), it's no longer >> pointing at a fundamental problem in Django itself that needs to be >> addressed before we cut a release candidate for 1.5. >> >> As for the lock itself -- you've pointed at a number of places where the >> lock *isnt'*, but you haven't pointed at where the lock *is*. Is it a >> database lock, or a processing loop lock? Is it on retrieving the session, >> or creating a session? Which line of code is locking? You've said you've >> done some print debugging -- what lines are (and aren't) executed? >> >> Ultimately, you're going to need to investigate this yourself -- I (and >> others) can give you hints of places to look, and seeing the code will help >> us, but you're the one with the live test case. >> >> Yours, >> Russ Magee %-) >> >> >> -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/tEDlysSgrysJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
