Fix 503 error when Jetty cancels a request

When we added the non-interactive execution queue we broke the
ability to cancel a pending project request that had been deferred
with a Jetty continuation.  When the timeout is reached we are
invoked through a different code path that bypasses the GuiceFilter,
which means we don't have access to the current user state.
That prevents us from finding the proper WorkQueue.Executor to
cancel the task from.

Remember the WorkQueue.Executor we pushed the task into, so we
can remove it from the same queue.

Bug: issue 614
Change-Id: I76344befc1c248cbd03f34d629d3ea15d9ef8bbf
Signed-off-by: Shawn O. Pearce <sop@google.com>
This commit is contained in:
Shawn O. Pearce 2010-07-13 10:32:41 -07:00
parent adaf5c3f95
commit 8943adf8dc
1 changed files with 5 additions and 3 deletions

View File

@ -111,7 +111,7 @@ public class ProjectQoSFilter implements Filter {
WorkQueue.Executor executor = getExecutor();
if (cont.isInitial()) {
TaskThunk task = new TaskThunk(cont, req);
TaskThunk task = new TaskThunk(executor, cont, req);
if (maxWait > 0) {
cont.setTimeout(maxWait);
}
@ -163,13 +163,16 @@ public class ProjectQoSFilter implements Filter {
private final class TaskThunk implements CancelableRunnable,
ContinuationListener {
private final WorkQueue.Executor executor;
private final Continuation cont;
private final String name;
private final Object lock = new Object();
private boolean done;
private Thread worker;
TaskThunk(final Continuation cont, final HttpServletRequest req) {
TaskThunk(final WorkQueue.Executor executor, final Continuation cont,
final HttpServletRequest req) {
this.executor = executor;
this.cont = cont;
this.name = generateName(req);
}
@ -219,7 +222,6 @@ public class ProjectQoSFilter implements Filter {
@Override
public void onTimeout(Continuation self) {
WorkQueue.Executor executor = getExecutor();
executor.remove(this);
}