Jetty Continuations problem

We did some heavy load testing and discover thread contention during using Continuations. Problem appeared near 10K BOSH users with 30 sec ping.

I recommend you replace org.jivesoftware.openfire.http.HttpConnection method

private String waitForResponse() throws HttpBindTimeoutException {
if (continuation.suspend(session.getWait() * JiveConstants.SECOND)) {
String deliverable = (String) continuation.getObject();
// This will occur when the hold attribute of a session has been exceded.
this.isDelivered = true;
if (deliverable == null) {
throw new HttpBindTimeoutException();
}
else if(CONNECTION_CLOSED.equals(deliverable)) {
return null;
}
return deliverable;
}
this.isDelivered = true;
throw new HttpBindTimeoutException("Request " + requestId + " exceeded response time from " +
“server of " + session.getWait() + " seconds.”);
}

by the

private String waitForResponse() throws HttpBindTimeoutException {
continuation.suspend(session.getWait() * JiveConstants.SECOND);
if (continuation.getObject() != null) {
String deliverable = (String) continuation.getObject();
// This will occur when the hold attribute of a session has been exceded.
this.isDelivered = true;
if(CONNECTION_CLOSED.equals(deliverable)) {
return null;
}
continuation.setObject(null);
return deliverable;
}
this.isDelivered = true;
throw new HttpBindTimeoutException("Request " + requestId + " exceeded response time from " +
“server of " + session.getWait() + " seconds.”);
}

Please, correct me, if i was wrong in my assumption.

Thanx!

(removed reply to wrong thread)

The code did evolve a lot so it may be very hard to apply this patch.

Consider a stock portfolio web application. Each browser will send a long poll request to the server asking for any of the user’s stock prices that have changed. The server will receive the long poll requests from all its clients, but will not immediately respond. Instead the server waits until a stock price changes, at which time it will send a response to each of the clients with that stock in their portfolio. The clients that receive the long poll response will immediately send another long poll request so they may obtain future price changes.

Thus the server will typically hold a long poll request for every connected user, so if the servlet is not asynchronous, there would need more than 1000 threads available to handle 1000 simultaneous users. 1000 threads can consume over 256MB of memory; that would be better used for the application rather than idly waiting for a price to change.If the servlet is asynchronous, then the number of threads needed is governed by the time to generate each response and the frequency of price changes. If every user receives a price every 10 seconds and the response takes 10ms to generate, then 1000 users can be serviced with just 1 thread, and the 256MB of stack be freed for other purposes.

mosaico artistico

__You’ll never know til’ you have try!__

1 Like