glassfish服务器没响应,在Internet Explorer中运行时Web应用程序与Glassfish服务器失去连接...

在Internet Explorer中使用我们的Web应用程序时，浏览器有时不会从Web服务器获得响应，并且应用程序最终会超时。在Internet Explorer中运行时Web应用程序与Glassfish服务器失去连接

该应用程序是一个使用IceFaces框架的Java Server Faces应用程序。当用户在应用程序中执行操作时，可以并行发出多个AJAX请求。当用户一次打开多个浏览器窗口(视图)时，可能会发生这种情况。一些AJAX请求不会返回浏览器的结果。

有时，某些AJAX请求可能会中止。我们相信，当浏览器选项卡/框架关闭并且存在未完成的请求时，Internet Explorer将中止它们。可能这些请求是使用以前被中止的请求所使用的连接，尽管我们还没有证明这一点。

当应用程序似乎挂在客户端(AJAX请求不返回)时，在服务器端，Glassfish的堆栈跟踪显示线程处于由Grizzly生成的NIO选择调用中。

例如：从线程池

堆栈跟踪：

http-thread-pool-16093(1)" - Thread [email protected]

java.lang.Thread.State: RUNNABLE

at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)

at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)

at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

- locked <768acb28> (a sun.nio.ch.Util$2)

- locked <121febe5> (a java.util.Collections$UnmodifiableSet)

- locked <6db810ae> (a sun.nio.ch.EPollSelectorImpl)

at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

at com.sun.grizzly.util.Utils.readWithTemporarySelector(Utils.java:159)

at com.sun.grizzly.util.SSLUtils.doRead(SSLUtils.java:185)

at com.sun.grizzly.util.SSLUtils.doSecureRead(SSLUtils.java:138)

at com.sun.grizzly.util.SSLUtils.doSecureRead(SSLUtils.java:101)

at com.sun.grizzly.util.InputReader.doSecureRead(InputReader.java:311)

at com.sun.grizzly.util.InputReader.doRead(InputReader.java:281)

at com.sun.grizzly.util.InputReader.read(InputReader.java:206)

at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:837)

at com.sun.grizzly.tcp.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:873)

at com.sun.grizzly.tcp.http11.filters.IdentityInputFilter.end(IdentityInputFilter.java:202)

at com.sun.grizzly.tcp.http11.InternalInputBuffer.endRequest(InternalInputBuffer.java:422)

at com.sun.grizzly.http.ProcessorTask.finishResponse(ProcessorTask.java:806)

at com.sun.grizzly.http.ProcessorTask.postResponse(ProcessorTask.java:782)

at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:758)

at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)

at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)

at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)

at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)

at com.sun.grizzly.ContextTask.run(ContextTask.java:71)

at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)

at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)

at java.lang.Thread.run(Thread.java:662)

Locked ownable synchronizers:

- locked <36cd6060> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

使用开发工具，我们看到的请求的典型模式，其中包括一个被中止的请求的Internet Explorer仍然在网络流量展望显示为待处理。

我们在Firefox或Chrome中没有看到这个问题，但我们可以在IE中可靠地重现它。 8,9 & 10.

有没有人遇到过这个问题？

2014-01-30

JaneH