Fix crash when client submits changeset based on too-old revision
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.pull/1025/head
parent
e16008b371
commit
f1b4206cad
|
@ -526,7 +526,11 @@ function handleUserChanges(client, message)
|
||||||
if(ERR(err, callback)) return;
|
if(ERR(err, callback)) return;
|
||||||
|
|
||||||
changeset = Changeset.follow(c, changeset, false, apool);
|
changeset = Changeset.follow(c, changeset, false, apool);
|
||||||
callback(null);
|
if ((r - baseRev) % 200 == 0) { // don't let the stack get too deep
|
||||||
|
async.nextTick(callback);
|
||||||
|
} else {
|
||||||
|
callback(null);
|
||||||
|
}
|
||||||
});
|
});
|
||||||
},
|
},
|
||||||
//use the callback of the series function
|
//use the callback of the series function
|
||||||
|
|
Loading…
Reference in New Issue