This was biting us before when the user would leave a narrow before a
get_old_messages call associated with it finished. Specifically,
search.maybe_highlight_message() would assume a message was in the
DOM when it wasn't any more.
We also have to hide the 'loading more messages' indicator when
reseting the 'load more' status because otherwise it wouldn't get
hidden like normal in the load_old_messages() continuation, causing a
load_more_messages() not to fire when re-entering a narrow.
(imported from commit 4a136dd01305b039c0970f897b07e603b87d5d8e)
This should substantially decrease the amount of server load generated
by the userpresence system.
I tested that this indeed was indeed saving one query on
/json/update_active_status requests on my laptop with 2 users from the
humbughq.com realm logged in.
(imported from commit 03e9d4eb95b9f664d489862684ae162db2076e08)
This cache filling code takes about 5 seconds to run, which means it
will finish before Tornado starts reading from this cache, but if that
were to change, it would be much better to have made at least some
progress.
(imported from commit 60a3420cdb9ddf331d83573a3fdb6be1a5ee5a4f)
Previously we were calling select_related() on Message.client, which
doesn't exist. It seems kinda poor that this doesn't raise an
exception.
I believe this issue was causing us to do very large numbers of
database queries during get_updates calls during server restarts.
(imported from commit b79bd698820fbd9dd82bd61fc175c32cd5ce6d05)
Previously, AdminEmailHandler would crash if the record did not
contain any exception information (e.g. because it came from
logging.error()).
(imported from commit 868ec68f3a57eddbb2c851ecf9894e5eddf21e4c)
Previously when we logged errors using logging.error() but didn't
throw an exception, we would send these totally useless error
humbugs/emails that look like this:
Error generated by Anonymous user (not logged in)
No stack trace available
This change makes those messages include the actual text passed to
logging.error(), which is substantially more useful.
(imported from commit 76a8220ffe66d19cb0ca8ba9d1b42d5ecc4fd511)
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)
If the user scrolls super fast, our scroll handler might not catch
the user passing by some messages.
(imported from commit 14cebffcd1321f02443971ac5e1c922db19648ab)
After this commit, we built an API tarball and sent it to
CUSTOMER4, and then promptly reverted the commit so that
we could continue as we had been before.
(imported from commit 662519a79edd508e7c115b451a7ec6fbdf1fc0a4)
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)
restart-server has been relatively slow recently, and it'd be nice to
know what it is spending its time doing when it hangs for a few
seconds.
(imported from commit a411c951f5a3f2a1366b6d5d3a40d0660ebec11b)
Since we flush memcached when we do a server restart, the flurry of
get_updates requests that fly in afterwards are all cache misses for
getting the User/UserProfile objects, so Tornado ends up spending
around 70ms per get_updates request rather than the usual 1-2ms.
So this should substantially improve our Tornado performance around
server restarts.
(imported from commit 07b8126bdfd4ff14e4c3362f9eda1fe5fd571c5b)
Our previous code could in theory end up clearing the caches it had
just filled, if Tornado's cache filling work happened to be faster
than the memcached flush.
(imported from commit 48174aadad398fb7a7c917a1df765c1261b12a55)
We create a circular reference between handler functions and our
wrappers for them so that we can pass the wrapper to jQuery.off when
users pass the original handler to us. This reference-counting
system can't break all the circular references we create because
users can unbind event handlers without explicitly naming the
handlers they want to remove (they can remove all bindings on an
element, for example). For now, we hope that this memory leak isn't
too bad.
(imported from commit 9615b5761b4b09ca7ca52c0d847e9b83330373fa)
Previously, we couldn't actually unbind some event handlers. The
problem was that when a user called $.off(events, handler), the
passed handler wouldn't match any that were actually bound because
the handler that was actually bound was our wrapper.
This bug specifically caused the handlers for our idle timers to
never be unbound, effectively never cancelling them.
(imported from commit 48efac954994a05c356d326e64a78ab0ace9fe3e)
We will need this for removing event handlers. This will
unfortunately create a memory leak, but we'll partially deal with
that later.
(imported from commit e439cb44d245e16d2254d1be053b68015a1f4c79)
Sometimes Dropbox shares with /s/ and sometimes with /sh/,
and I'm not sure which controls it, but we should deal with both.
(imported from commit 2222450f25c418b5fbd60ab2c30477467e34c0d1)
Tim Abbott
Zev Benjamin
Leo Franchi
Waseem Daher