7 Replies Latest reply on Aug 7, 2007 3:37 PM by Igor Shabalov

    Problem Running a4j on Jrun4

    martin di bella Newbie

      Hi, while trying to run a simple MyFaces+RichFaces+A4J on Jrun4, caught an exception: StackOverFlowException. After a code analysis, found that the error was produced because the server sets the FilterServletResponseWrapper.bufferSize to zero(0). Setting bufferSize to zero causes CharBuffer to enter an infinite loop.
      I wasn't able to change it (tried <%@ page buffer="16kb"%>), but still set to zero, it looks like hardcoded.
      The thing is a tested the same application with tomcat and worked fine (because Tomcat didn't call FilterServletResponseWrapper.setBufferSize).

      Does anybody know how NOT to care about what the JSP Engine says about bufferSize? Do you know any solution to this problem? Is the servlet container doing wrong?

      Thanks.
      Martin.

        • 1. Re: Problem Running a4j on Jrun4
          Igor Shabalov Apprentice

          You need to post a stacktrace.
          It is not clear where the problem resides - in Jrun, MyFaces of A4J.

          • 2. Re: Problem Running a4j on Jrun4
            martin di bella Newbie

            Sorry I forgot to say: ajax4jsf version: 1.1.0.

            Here's the stacktrace:

             javax.faces.FacesException: javax.servlet.ServletException
             at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:429)
             at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:211)
             at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
             at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:229)
             at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
             at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
             at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140)
             at org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:77)
             at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
             at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96)
             at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220)
             at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
             at jrun.servlet.FilterChain.service(FilterChain.java:101)
             at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
             at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
             at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:252)
             at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527)
             at jrun.servlet.http.WebService.invokeRunnable(WebService.java:168)
             at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:451)
             at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
            Caused by: javax.servlet.ServletException
             at jrun.jsp.runtime.Utils.handleException(Utils.java:61)
             at jrun.jsp.runtime.JRunPageContext.handlePageException(JRunPageContext.java:384)
             at jrun__aView2ejspa._jspService(jrun__aView2ejspa.java:181)
             at jrun.jsp.runtime.HttpJSPServlet.service(HttpJSPServlet.java:43)
             at jrun.jsp.JSPServlet.service(JSPServlet.java:119)
             at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
             at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
             at jrun.servlet.JRunRequestDispatcher.invokeNext(JRunRequestDispatcher.java:439)
             at jrun.servlet.JRunRequestDispatcher.forwardInvoke(JRunRequestDispatcher.java:409)
             at jrun.servlet.JRunRequestDispatcher.forward(JRunRequestDispatcher.java:178)
             at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:419)
             ... 19 more
            
            
             javax.servlet.ServletException: javax.servlet.ServletException
             at javax.faces.webapp.FacesServlet.service(FacesServlet.java:154)
             at org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:77)
             at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
             at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96)
             at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220)
             at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
             at jrun.servlet.FilterChain.service(FilterChain.java:101)
             at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
             at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
             at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:252)
             at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527)
             at jrun.servlet.http.WebService.invokeRunnable(WebService.java:168)
             at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:451)
             at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
            


            The stacktrace itself doesn't say anything revealing. But while debugging, I found that the root cause was a StackOverFlowException.
            In my previous post, I tried to explain what I found in code analysis, I'll try to make it more clear.

            The first thing I noticed was that the recursive infinite loop that was causing the StackOverFlowException was inside org.ajax4jsf.io.CharBuffer, more exactly in the append(char[] cs, int off, int len), line 112, where a new CharBuffer is created.
            The next thing I tried to know was why it kept creating CharBuffers until stack overflow. The answer was that the cacheSize attribute of CharBuffer was set to zero. So, while debugging realized that none of the condition in the append(...) method was met, reaching the end of the method again, and creating a new CharBuffer, and so on...
            After realizing that zero was not an expected value for the cacheSize attribute, try to figure out who was setting that property to zero. The answer was the the JSP engine (Jrun's in this case) was calling the setter method setBufferSize(...) of HttpServletResponse (in our case, javax.servlet.http.HttpServletResponseWrapper) to zero, no matter what.
            As a final test, tried to run the same example on Tomcat 4.1. It worked, the thing is that the setBufferSize(...) method was not called at all by the Tomcat's JSP Engine.

            Hope had been clear enough :).
            Thank you very much for your fast reply.
            Martin.

            • 3. Re: Problem Running a4j on Jrun4
              Igor Shabalov Apprentice

              Thank you Martin. Looks like simple bug, that we can fix :-).

              • 5. Re: Problem Running a4j on Jrun4
                Igor Shabalov Apprentice

                Fixed, will be included into tomorrow snapshot.

                • 6. Re: Problem Running a4j on Jrun4
                  martin di bella Newbie

                  Thank you very much, one last question: How can I get the snapshot including this fix?

                  • 7. Re: Problem Running a4j on Jrun4
                    Igor Shabalov Apprentice

                    http://maven.exadel.com/org/richfaces/ui/richfaces-ui/3.1.0-SNAPSHOT/

                    But note that today snapshot is not yet built and in general snapshots are a bit shaky this week.