But discard any changes the Django response middleware may have made
to anything other than the content.
This allows us to, for example, output our nice database query logging
for get_updates requests.
(imported from commit e1d2fd38ceb4d73ff50bdfaad7c72ddb24d0fe16)
This is preparatory for running the Django response middleware on
our Tornado responses.
(imported from commit 05da8ea9cb663a928b2f98a928f3992aae4f067c)
This will mainly be useful in the event system branch, where we want
to actually send a response from a file other than tornadoviews.py.
(imported from commit b7ae9bb9b062215ab44eb5f0a3a72d6baeee1d07)
With this change,
pkill -SIGUSR1 -f runtornado
will dump the stack and SIGUSR2 will enable an interactive debugging
session.
This fixes#613 for Tornado which was the original motive for that
ticket; I'm not sure whether we want to do this for our Django
processes as well, but it would be easy to do so if we did.
(imported from commit a7de7c6070f4bf0404bed6f434e6a6b291d66a26)
This commit has the effect of eliminating all of the non-UserActivity
database queries from the Tornado process -- at least in the uncached
case.
This is safe to do, if a bit fragile, since our Tornado code only
accesses these objects (as opposed to their IDs) in a few places that
are all fine with old data, and I don't expect us to add any new ones
soon:
* UserActivity logging, which I plan to move out of Tornado entirely
* Checking whether we're authenticated in our decorators (which could
be simplified -- the actual security check is just whether the
Django session object has a particular field)
* Checking the user realm for whether we should sync to the client
notices about their Zephyr mirror being up to date, which is quite
static and I think we can move out of this code path.
But implementation constraints around mapping the user_ids to
user_profile_ids mean that it makes sense to get the actual objects
for now.
This code is not what I want to do long-term. I expect we'll be able
to clean up the dual User/UserProfile nonsense once we integrate the
upcoming Django 1.5 release, with its support for pluggable User
models, and after that I change, I expect it'll be fairly easy to make
the Tornado code only work with the user ID, not the actual objects.
(imported from commit 82e25b62fd0e3af7c86040600c63a4deec7bec06)
Note that on local dev servers, this will print out every half second, as
Tornado polls for file changes for autoreloading. In production it will only
print out when network events occur.
(imported from commit adfe88879e4e446b7dfa6ee69e0a9ad013e9c4d4)
tornado.web already does this, based on the setting of the 'debug' kwarg.
Dropping this in production saves us waking up twice a second to stat()
a bunch of files.
We already explicitly restart the server on deploys.
(imported from commit 283bb0da609acb2699a04111a74c13224fe5124c)
This was causing us to log some requests twice, and might have more serious
consequences as well.
(imported from commit 0bb2d7207ee3e4e04679215a7f5ae637cd26aa19)
The zero-port case never actually worked, because addrport wasn't an optional
parameter in run_one. And multiple ports was implemented using the
multiprocessing library, which is just bad news. Since we have no need for
this, remove it before it can cause trouble.
(imported from commit 9d913924701f30d23ebe878b76c8f1f0da2800e2)
This is the behavior specified by Django. Since this was broken before,
our CSRF protection had no effect on Tornado views other than printing
a warning message :(
(imported from commit 7975d3c9b6c18915f917ac2da4592a55f6b6a658)
The client may now optionally send its current pointer during
get_updates and the server will return the latest pointer if it
differs and was updated more recently by a different session.
(imported from commit e43b377d7dfb52f83cefb0b1003863d5407caf80)
The code is buggy; the variable 'escape' is undefined. Right now we aren't
using this code because we bypass Tornado for login.
(imported from commit 91cf6e8fc9477039c8847c7e9501d645993278b8)
Tim Abbott
Zev Benjamin
Keegan McAllister