We had a problem with the server running out of stack space if a client submitted a changeset based on a revision more than about 1000 revs old. (944 was our cutoff but yours may vary). This happened in the wild with about 30 people editing via flaky wifi. A disconnected client would try to submit a fairly old changeset when reconnecting, and a few minutes was enough for 30 people to generate that many revs. The stack kept growing because pad.getRevisionChangeset was being answered from the cache, so no I/O interrupted the callback chain. (This was seen with mysql, I don't know about other backends.) This patch forces a nextTick every 200 revisions to solve this problem.
When stress testing etherpad-lite we occasionally got this error: TypeError: Cannot read property 'author' of undefined at /home/etherpad/etherpad-lite/src/node/handler/PadMessageHandler.js:556:47 handleUserChanges was accessing sessioninfos[client.id].author in a callback, after spending some time in the loop that updates the changeset to the latest revision. It's possible for a disconnect request to be processed during that loop so the session might no longer be there. This patch fixes it by looking up the author at the start of the function.
…session in cookie." This reverts commit 443a71b. modified: src/node/db/SecurityManager.js
Fixes issue introduced in 9be69ef.
moved inInternationalComposition from Ace2Inner to top window fix bindTheEventHandlers() because ie9 implement CompositionEvent when inInternationalComposition, NEW_CHANGES msg and ACCEPT_COMMIT msg are pushed msgQueue. when handleUserChanges(), apply msgQueue.