我在Jersey + Grizzly中实施longpoll。为了测试我的问题,我现在只有带有asyncResponce的资源,即挂起的请求。像这样:
@GET
@Produces("application/json")
public void asyncGetWithTimeout(@Suspended final AsyncResponse asyncResponse) {
asyncResponse.setTimeoutHandler(new TimeoutHandler() {
@Override
public void handleTimeout(AsyncResponse response) {
response.resume(Response.status(Response.Status.SERVICE_UNAVAILABLE)
.entity("{\"response\":\"timeout\"}").header("Access-Control-Allow-Origin", "*").build());
}
});
asyncResponse.setTimeout(30, TimeUnit.SECONDS);
}
一切正常,直到被挂起的请求数超过7。然后整个Web应用程序陷入阻塞,甚至是常规同步请求。怎么可能,在Jersey中只有7个线程?抱歉,我并发和Web应用程序不是很好,只是没想到会出现这种问题。
最佳答案
我解决了实际上存在一个客户端问题,称为“每个主机名的最大连接数”。此数字是特定于浏览器/应用程序的。因此,我在Chrome中测试了我的Web应用程序并获得了7。如您从下表中看到的那样,我只是将计算错误了1。
每个服务器/代理的默认默认同时持久连接数:
Firefox 2: 2
Firefox 3+: 6
Opera 9.26: 4
Opera 12: 6
Safari 3: 4
Safari 5: 6
IE 7: 2
IE 8: 6
IE 10: 8
Chrome: 6