我在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

10-08 01:40