JSF1064：Primefaces 无法加载资源

Question

我知道这个问题已经被多次提出，并且我已经阅读了谷歌的论坛帖子页面，但我仍然没有找到明确的解决方案。问题是某些 primefaces 资源无法提供服务，导致超时异常：

JSF1064：无法从库 primefaces 中找到或提供资源 schedule/schedule.js。 java.io.IOException: java.util.concurrent.TimeoutException

错误并不总是针对某个特定资源，它可能有很多（大部分时间是 schedule.js），而且只有大约 60% 的时间会发生。

我什至尝试过手动输出脚本和 css 文件，但无济于事。所有 primefaces jar 都在相应的 WEB-INF/lib 文件夹中。

Web.xml：

<?xml version="1.0" encoding="UTF-8"?> <web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"> <context-param> <param-name>javax.faces.PROJECT_STAGE</param-name> <param-value>Development</param-value> </context-param>
<context-param> <param-name>primefaces.THEME</param-name> <param-value>home</param-value> </context-param> <servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>*.xhtml</url-pattern> <url-pattern>*.jsf</url-pattern> </servlet-mapping> <session-config> <session-timeout> 30 </session-timeout> </session-config> <welcome-file-list> <welcome-file>index.xhtml</welcome-file> </welcome-file-list> </web-app>

堆栈跟踪：

    WARNING:   JSF1064: Unable to find or serve resource, schedule/schedule.js, from    library, primefaces.
    WARNING:   java.io.IOException: java.util.concurrent.TimeoutException
    at org.glassfish.grizzly.utils.Exceptions.makeIOException(Exceptions.java:81)
    at     org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:958)
    at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:682)
    at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
    at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
    at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
    at java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
    at    com.sun.faces.application.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandler    Impl.java:343)
    at java x.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
    at org.primefaces.application.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:132)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
    at java.lang.Thread.run(Thread.java:722)
Caused by: java.util.concurrent.TimeoutException
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:258)
    at java.util.concurrent.FutureTask.get(FutureTask.java:119)
    at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:951)
    ... 36 more

Answer 1

此问题记录为 Glassfish 错误 #20681。这是 Glassfish 4 中的 Grizzly（HTTP 服务器）版本的问题。

有两个问题在起作用。首先是小的套接字写入缓冲区大小。 RH 和 Ubuntu 上的默认写入缓冲区大小为 16K。在 Grizzly 中，为了节省内存，只会 在我们阻止写入器之前，允许 4 倍的写入缓冲区大小排队。在附加的测试用例中，有几个超过 200K 的工件。当这些被写入时，默认 Servlet 进行的初始写入将超过最大排队数据大小并导致写入器阻塞。由于所有工作线程都被阻塞，异步写入队列不再被耗尽，并且就用户而言，页面在加载时挂起。这是第二个问题的来源。默认情况下，只有五个工作线程。在测试用例的情况下，至少有五个请求请求大量资源。因此，所有工作线程都被阻塞，所有 I/O 都停止。

正如所观察到的，增加 GF 使用的写入缓冲区大小有助于缓解问题，但会以每个连接的内存为代价。也可以增加线程数量，但不能保证在增加客户端数量时所有这些线程最终都不会被阻塞。