I tried to add sleep(30) at the first line of my view. After that I opened this page in two browser tabs. The first tab loaded the page after 30 seconds, and the second one loaded it in 60 seconds. In the meantime I was able to open pages from another pc just fine. So it looks like Django blocks the concurrent requests from the same client.
This is very well for my app. And I'd like to be sure my site will work this way in the future. However I have not found any documentation or articles describing such Django behaviour. So I'm still not sure if this is a feature or just fortune. Could somebody please explain how and why this works?
What I actually need is to block the session while view is processing. Of course I can use some flags or db transactions. But I'd not like to add a feature that is already implemented in Django.
I use python 2.6.5, django 1.4, ubuntu server, nginx and uwsgi. Tried both postgresql and sqlite.
My uwsgi settings:
<uwsgi>
<pythonpath>/home/admin/app/src</pythonpath>
<app mountpoint="/">
<script>deploy.wsgi</script>
</app>
<workers>4</workers><!-- Not sure this is needed -->
<processes>2</processes>
</uwsgi>
I also got same effect with runserver command.
Actually Django does not block simultaneous requests.
If I run two browsers (for example chrome and firefox) with the same session (by copying the sessionid cookie from the first browser to the second one), blocking does not happen. So, this is a browser feature, and it's not related to Django anyhow. This means I still need to add some blocking feature by myself to make the code safe.
Related
I have a problem with (I think) Flask Login.
The project is a keyword tracking on Google.
I have a page, which lists all the keywords in a chart (ChartJs).
It's a loop. For each keyword, I generate a chart that retrieves all the positions in the database.
Before, I did not use Flask Login. I was blocking ips via htaccess.
Everything worked fine. The (approximately) 80 keyword graphs loaded without problems.
But since I use Flask Login, only 3 graphics load.
When I want to reload the pager OR go to another page of the site, I get disconnected.
With this information, can you see what the problem is?
What script from the project should I share to make it clearer?
thanks
I'm building a webapp using gunicorn, flask, and plotly's dash. I'm using guncorns's --reload option which automatically reloads or resets the workers if any code is modified. I have observed this basically restarts my entire web app. At the start of my webapp I'm initializing a client connection and cursor to documents inside a mongo db. Then the webapp starts graphing stuff. If I modified the HTML of the webapp, I want gunicorn to reload the HTML side of things only, and not reinitialize the mongo db each time. Is there any way I can avoid reloading everything using gunicorn's reload? Or maybe some other alternative?
Gunicorn only reloads the Python code. It will not reload your HTML code.
Your HTML code should be read each time a request is made, unless it is using cached version.
Try disabling cache on the page which you are trying to re-load.
These links should point you towards a solution:
https://pythonhosted.org/Flask-Caching/
https://gist.github.com/arusahni/9434953
Disable cache on a specific page using Flask
I have a weird bug with django sessions in my app: some times (about 10 times for ~20000 per day) session information for user is erased. I traced it via log files: at page A there is information for user's session, after it he submits the form and at the next page his session is empty. I tried two types of storage: memcached+db and db only and this problem is for both of them. I tried to reproduce these scenarios, but all works as expected, as I said, it happens very rare. I also checked that this problem exists for different users, and for them is doesn't reproduce each time. I don't have any ideas how to catch the root cause and I don't know what else post here as a description. If someone has any ideas, please let me know. If it is important, I'm running my app with django 1.2 + FastCGI.
Thanks!
UPD: I checked and see that session key from uses is not changed during two sequential requests, at first request there is an actual session state, and at second session variables are relaced with empty.
As a way to debug this problem, I would subclass the standard Django session middleware (or whatever you're currently using):
django.contrib.sessions.middleware.SessionMiddleware
and wrap process_request and (probably more importantly) process_response in some extra logging. Then install your subclassed session middleware in the MIDDLEWARE_CLASSES, rather than the stock Django one.
You could also validate that session.save() has actually committed its changes by attempting to read it back. It could be that the problem lies in session-state serialisation, and it's failing on a particular key or value that you're attempting to store.
None of this will fix your problem, but it might help you to establish what's going on.
As #Steve Mayne mentioned, it would be good to do some logging on the sessions middleware and sessions model save method. That's something I'd start with.
In addition I'd like to say that this could be a database related issue, especially if you're using MySQL database backend for sessions. You can check the log for database locks and other concurrency issues. I had to deal with similar issues before and the solution is clear: optimization and additional performance.
If you have some specific application middleware, you can check for functionality that interferes with Django sessions. Such parallel operations can cause problems, if not implemented properly.
Another thing I would do is to upgrade to the latest stable release of Django and migrate to a mod_wsgi setup.
First let me say that this is not about production settings for django - it's for local development and testing.
I'm testing out multiple user scenarios, requiring I log in as several different users. I'm logged in as user A using Chrome, and user B using Chrome's incognito mode, and as user C using Firefox. I'm using "manage.py runserver" to run the dev server.
The first instance with regular Chrome (user A) works well and is fast. The other instances are very slow - perhaps better described as stuck. They sit around doing nothing for 10-30 seconds, and then finally display the page fairly quickly.
While the other browsers are stuck I can go to the first one (user A) and click around and it works well and is fast. In other words only the requests from the other two instances get stuck - the first instance always works well.
The resource that's slow appears to be the html page, not the static content.
The backend is Django 1.1.1 with SQLite as the database running on OS X 1.6.7 .
Any ideas? Is Chrome doing something special to hog the connection?
This could be a known issue "Development web server sometimes hangs with Chrome":
https://code.djangoproject.com/ticket/16099
It is fixed recenty in django trunk:
https://code.djangoproject.com/changeset/16427
Esteemed Django experts and users:
I have been using Django's admin interface for some data editing needs. I am using it on Windows Server 2008, and using django-mssql to connect to a SQL Server backend. Python 2.6.2 Django 1.1.0 final 0
As per usual w/ Django, this was fairly easy to set up, and works beautifully on Firefox, but using IE8 I intermittently get a puzzling 'Internet Explorer cannot display this webpage' when I save a record.
In the log, looks like typically on a save there's a POST request that returns a 302 status followed by a GET returning a lovely 200. This is on Firefox. On IE8 looks like sometimes POST works but GET doesn't.
So that's what I have going on. Any help w/ this will be appreciated. Thank you.
I suspect the bug is within IE8's refusal to process the redirect properly.
The 302 POST pushes to browser to the 200 GET, but if the browser never processes the 302 then the Django (or the server) will not log a 200 GET because the browser never opened the page (the server can only log what is accessed, ergo the browser is not making the call).
If you have Django behind something (IIS using FastCGI, or Apache, or something), bump up the logs to make sure there's no silent error in rendering. I had the same problem on Vista x64 Ultimate IE8 Beta 2, but compatibility mode appeared to fix the problem somewhat -- there was still some intermittently occurring refusal to redirect.
I realize this post is a bit old now, but I had the exact same symptoms recently. After a lot of digging around, I found that IE8 has issues accepting cookies with a life of less than 20 minutes.
In our Django project's settings.py we had the property SESSION_COOKIE_AGE set to 10 minutes. Once I bumped it to 20 minutes, IE8 had no problems logging in.