[英]java/jsf strange error: WARNING: StandardWrapperValve PWC1406: Servlet.service() … threw exception java.lang.NullPointerException
I have simple jsf app with servlet for dynamic images and filter setting utf8 encoding. 我有简单的jsf应用程序与servlet动态图像和过滤器设置utf8编码。 From time to time (1/10 requests) I get very strange error:
不时(1/10请求)我得到非常奇怪的错误:
WARNING: StandardWrapperValve[com.webapp.servlet.ImageServlet]: PWC1406: Servlet.service() for servlet com.webapp.servlet.ImageServlet threw exception
java.lang.NullPointerException
at com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectionKeyHandler$CloseHandler.notifyClosed(MonitorableSelectionKeyHandler.java:94)
at com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectionKeyHandler$CloseHandler.remotlyClosed(MonitorableSelectionKeyHandler.java:90)
at com.sun.grizzly.BaseSelectionKeyHandler.notifyRemotlyClose(BaseSelectionKeyHandler.java:233)
at com.sun.grizzly.util.OutputWriter.notifyRemotelyClosed(OutputWriter.java:353)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:148)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:326)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:398)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:376)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1247)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:380)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:353)
at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:175)
* at com.webapp.servlet.ImageServlet.doGet(ImageServlet.java:35)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:118)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
* at com.webapp.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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:722)
Here's my servlet and filter, I marked with asterisks lines referencing to stacktrace: 这是我的servlet和过滤器,我标有引用stacktrace的星号行:
@WebServlet(urlPatterns = "/images/*")
public class ImageServlet extends HttpServlet {
@Inject
private FileService fileService;
@Override
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
byte[] img = fileService.getImage(request.getPathInfo());
if (img != null) {
response.setContentType("image/png");
response.addHeader("Content-Length", String.valueOf(img.length));
ServletOutputStream os = response.getOutputStream();
os.write(img);
* os.flush();
os.close();
} else {
response.sendRedirect(request.getContextPath() + "/error");
}
}
}
@WebFilter(urlPatterns = "/*")
public class CharacterEncodingFilter implements Filter {
@Override
public void init(FilterConfig filterConfig) {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
request.setCharacterEncoding("UTF-8");
response.setCharacterEncoding("UTF-8");
* chain.doFilter(request, response);
}
@Override
public void destroy() {
}
}
I have completely no idea what's going on... I'm using Glassfish 3.1.1 web profile with jdk7 我完全不知道发生了什么......我正在使用带有jdk7的Glassfish 3.1.1 web profile
Flushing is already implicitly done when you close the stream. 关闭流时已隐式执行刷新。 Closing is already implicitly done by the container itself.
关闭已经由容器本身隐式完成。 You actually do not need to do it yourself.
实际上,你不需要自己做。 However, most servlet developers do it to have early feedback for the case they overlooked that something else further in the request-response chain is writing to the output stream, eg a buggy filter or response wrapper or something.
但是,大多数servlet开发人员都会对他们忽略的情况进行早期反馈,即请求 - 响应链中的其他内容正在写入输出流,例如错误的过滤器或响应包装器等。 This would then result in an
IOException
on every call because the stream is closed. 这将导致每次调用都发生
IOException
,因为流已关闭。
In any case, you have 2 options to treat the flush()
and close()
: 在任何情况下,您有2个选项来处理
flush()
和close()
:
try-catch
wherein you ignore the exception. try-catch
,您可以忽略该异常。 This exception is just a sign that the client aborted the connection. 此异常仅表示客户端中止了连接。 Eg pressed [Esc] or closed the window/tab or navigated away to a different page while the image is still streaming.
例如,按下[Esc]或关闭窗口/标签,或在图像仍然流式传输时导航到另一个页面。
at com.sun.grizzly.util.OutputWriter.notifyRemotelyClosed()
Somehow this looks to me as if the connection you are flushing the stream of has intermediately been closed by the remote peer (a web browser?). 不知何故,这看起来好像你正在刷新流的连接已经被远程对等体(Web浏览器?)中间关闭了。
Can you try response.flushBuffer()
instead. 你可以尝试使用
response.flushBuffer()
。 Does this also throw the exception? 这也会抛出异常吗?
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.