Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.7DR#2
-
Fix Version/s: 1.7.2
-
Component/s: None
-
Labels:None
-
Environment:ICEfaces, glassfish-v2-ur1-b08
-
Workaround Exists:Yes
-
Workaround Description:
Description
GlassFish/Grizzly integration is now working well with the auctionMonitor, however occasional NullPointerExeptions were seen with WebMC. The following workaround and debugging code was applied for this. The NullPointerException is due to the getScheme() returning null on the request. A current version of GlassFish must be tested with WebMC to verify this.
+++ src/com/icesoft/faces/webapp/http/servlet/ServletRequestResponse.java (working copy)
@@ -45,7 +45,18 @@
public void servlet(Object request, Object response) {
HttpServletRequest req = (HttpServletRequest) request;
String query = req.getQueryString();
- URI uri = URI.create(req.getRequestURL().toString());
+ URI uri = null;
+ try {
+ uri = URI.create(req.getRequestURL().toString());
+ } catch (Exception e) {
+ System.out.println("building our own URI " + e);
+ uri = URI.create("http://" + req.getServerName() + ":"
+ + req.getServerPort() + req.getRequestURI());
+ System.out.println("Constructing URI " + uri + " scheme " + req.getScheme());
+ }
+ }
requestURI = (query == null ? uri : URI.create(uri + "?" + query));
}
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The catch block is also being hit when using Jboss 4.0.3 so this code should not be removed as per the comment:
//TODO remove this catch block when GlassFish bug is addressed
Here is the exception:
08:57:45,632 ERROR [ServletRequestResponse] Null Protocol Scheme in request
java.lang.NullPointerException
at org.apache.catalina.core.ApplicationHttpRequest.getRequestURL(ApplicationHttpRequest.java:465)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse$1.servlet(ServletRequestResponse.java:51)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.detectEnvironment(ServletRequestResponse.java:209)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.<init>(ServletRequestResponse.java:44)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.<init>(ThreadBlocking AdaptingServlet.java:32)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.service(ThreadBlockingAdaptingServlet.java:18)
at com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:29)
at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:109)
at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:35)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:359)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:54)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
08:57:55,631 ERROR [ServletRequestResponse] Null Protocol Scheme in request
java.lang.NullPointerException
at org.apache.catalina.core.ApplicationHttpRequest.getRequestURL(ApplicationHttpRequest.java:465)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse$1.servlet(ServletRequestResponse.java:51)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.detectEnvironment(ServletRequestResponse.java:209)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.<init>(ServletRequestResponse.java:44)
Tyler
..................................
Removing the logging is a good fix for the customer, but the fact that we're also seeing this Exception on JBoss indicates a more serious problem: multithreaded access to a request object or access to a stale request object (out of the scope of the service() method).
Mandeep, please comment on whether you have seen the reported exception in the test logs for glassfish or JBoss.
Comment from Jeanfrancois:
I was able to reproduce the problem...this is not simple to track down but I'm 98% sure this is an application bug. It seems the Request object is invoked by two threads, the normal one (Grizzly), and the Reader Thread. Once thread call the recycle method() where the scheme get null, and the other just after call the getScheme(). If I don't set that value to null when recycling, I'm not able to reproduce the problem.
If thread-1 has a reference to Request, then if you spawn Thread-2 from Thread-1 and if Thread-1 call recycle() before Thread-2 call getScheme(), the same exception will occurs. As soon as the service() method exit (assuming you aren't using Comet), the Request.recycle() will be invoked.
Issue as reported in the glassfish issue tracker:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3881
(They didn't continue to work on it because I admitted that it could easily be an application bug.)
Has the original problem been verified by QA? If so, they can mark as resolved if it's verified fixed.
A supported customer is getting a similar error on Tomcat 5.0.28 with ICEfaces 1.7.1 and in IE7. They are updating data that is linked to a chart they have in their application. The error is thrown on every update. Here is the error they are getting:
2008-07-16 10:43:51,230 [http-8080-Processor25] ERROR http.servlet.ServletRequestResponse - Null Protocol Scheme in request
java.lang.NullPointerException
at org.apache.coyote.tomcat5.CoyoteRequest.getRequestURL(CoyoteRequest.java:2068)
at org.apache.coyote.tomcat5.CoyoteRequestFacade.getRequestURL(CoyoteRequestFacade.java:511)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse$1.servlet(ServletRequestResponse.java:54)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.detectEnvironment(ServletRequestResponse.java:222)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.<init>(ServletRequestResponse.java:47)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.<init>(ThreadBlockingAdaptingServlet.java:32)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.service(ThreadBlockingAdaptingServlet.java:18)
at com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:63)
at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:139)
at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:53)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:595)
This has been reduced to debug level logging to reduce the symptoms of the problem. However, the bug still remains. Does the customer have a test case that we could use to solve the root cause?
Fixes are now checked in to the trunk and branches/icefaces-1.7
I am currently unable to reproduce this bug, but I believe that Jack has seen it on his system. Jack, can you confirm this?
Marking this as resolved, since the workaround is checked in. However, we still need to verify that this is indeed a GlassFish bug (not an ICEfaces bug) and advocate the fix in GlassFish.