You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Felipe Jaekel <fk...@gmail.com> on 2014/07/16 13:52:23 UTC
Help with java.lang.IllegalStateException: Cannot change buffer size
after data has been written
Not sure if this is this a MyFaces issue, but as I don't remember having it
when my projects were running with with Mojarra, I'd like to see if you can
help me.
I'm eventually seeing this exception in my Tomcat 7.0.47 log:
java.lang.IllegalStateException: Cannot change buffer size after data
has been written
at org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:254)
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.setResponseBufferSize(ServletExternalContextImpl.java:620)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.createResponseWriter(FaceletViewDeclarationLanguage.java:2241)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1861)
at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:313)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:200)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:105)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at br.com.spdata.cliente.filter.LoginFilter.doFilter(LoginFilter.java:43)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1721)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1679)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
It happens in different pages, but since the exception doesn't happen in
any of my managed beans, I have no idea of what is happening.
Currently I'm using MyFaces 2.2.4, but this was happening with previous
2.2.x releases too.
Any ideas?
Thanks in advance.
Re: Help with java.lang.IllegalStateException: Cannot change buffer
size after data has been written
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
how large is your page? maybe you need a larger buffer.
On Thu, Jul 24, 2014 at 3:39 PM, Felipe Jaekel <fk...@gmail.com> wrote:
> The 64K buffer didn't worked.
>
> Any other idea?
>
> Thanks
>
>
> 2014-07-16 11:33 GMT-03:00 Howard W. Smith, Jr. <sm...@gmail.com>:
>
> > On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel <fk...@gmail.com>
> wrote:
> >
> > > Not sure if this is this a MyFaces issue, but as I don't remember
> having
> > it
> > > when my projects were running with with Mojarra, I'd like to see if you
> > can
> > > help me.
> > >
> > > I'm eventually seeing this exception in my Tomcat 7.0.47 log:
> > >
> > > java.lang.IllegalStateException: Cannot change buffer size after data
> > > has been written
> > > at
> > >
> >
> org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:254)
> > >
> >
> > Felipe,
> >
> > I think I saw that error long time ago and I discussed with BalusC on/via
> > OmniFaces google-code project's issue tracker.
> >
> > anyway, I think it was caused by the largest XHTML page in my app, which
> > has hundreds of UI components (<input/>, etc...).
> >
> > Below, is what I saved in my web.xml per that discussion with BalusC.
> >
> >
> > <!--
> > http://code.google.com/p/omnifaces/issues/detail?id=73
> > Comment 25 by project member balusc, Today (11 minutes ago)
> > Just keep GZIP filter threshold size default. It has not the same
> > meaning as Facelets buffer size.
> >
> > A large Facelets buffer size may be useful during development, to
> spot
> > any bugs in the view which causes exceptions during render response. But
> I
> > would not set it that large in production.
> >
> > http://code.google.com/p/omnifaces/issues/detail?id=51
> > It's technically not possible to change the response when it has
> > already been committed.
> > So if an exception occurs during rendering the response and the
> > response has already been committed,
> > then you'll end up with a broken response. In most default
> > servletcontainer/webapp configurations,
> > the response get committed when 2KB has already been written to the
> > response.
> >
> > One of the ways to avoid this is to increase the response buffer
> size.
> > In Facelets,
> > you can do this using the following context parameter (which sets it
> to
> > 64KB, you may
> > if necessary need to adjust it to the size of the largest HTML output
> > you have):
> >
> > <context-param>
> > <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
> > <param-value>65535</param-value>
> > </context-param>
> >
> > Setting to 800KB, since /orders/pf_Add.xhtml (640+ KB) is the largest
> > view;
> > if this is not set, then OmniFaces 1.2 (OmniPartialViewContext)
> breaks
> > pf_BrowsePayroll.xhtml,
> > see OmniFaces issue 73 (URL above)
> > <context-param>
> > <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
> > <param-value>819200</param-value>
> > </context-param>
> > -->
> > <context-param>
> > <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
> > <param-value>65535</param-value>
> > </context-param>
> >
>
Re: Help with java.lang.IllegalStateException: Cannot change buffer
size after data has been written
Posted by Felipe Jaekel <fk...@gmail.com>.
The 64K buffer didn't worked.
Any other idea?
Thanks
2014-07-16 11:33 GMT-03:00 Howard W. Smith, Jr. <sm...@gmail.com>:
> On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel <fk...@gmail.com> wrote:
>
> > Not sure if this is this a MyFaces issue, but as I don't remember having
> it
> > when my projects were running with with Mojarra, I'd like to see if you
> can
> > help me.
> >
> > I'm eventually seeing this exception in my Tomcat 7.0.47 log:
> >
> > java.lang.IllegalStateException: Cannot change buffer size after data
> > has been written
> > at
> >
> org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:254)
> >
>
> Felipe,
>
> I think I saw that error long time ago and I discussed with BalusC on/via
> OmniFaces google-code project's issue tracker.
>
> anyway, I think it was caused by the largest XHTML page in my app, which
> has hundreds of UI components (<input/>, etc...).
>
> Below, is what I saved in my web.xml per that discussion with BalusC.
>
>
> <!--
> http://code.google.com/p/omnifaces/issues/detail?id=73
> Comment 25 by project member balusc, Today (11 minutes ago)
> Just keep GZIP filter threshold size default. It has not the same
> meaning as Facelets buffer size.
>
> A large Facelets buffer size may be useful during development, to spot
> any bugs in the view which causes exceptions during render response. But I
> would not set it that large in production.
>
> http://code.google.com/p/omnifaces/issues/detail?id=51
> It's technically not possible to change the response when it has
> already been committed.
> So if an exception occurs during rendering the response and the
> response has already been committed,
> then you'll end up with a broken response. In most default
> servletcontainer/webapp configurations,
> the response get committed when 2KB has already been written to the
> response.
>
> One of the ways to avoid this is to increase the response buffer size.
> In Facelets,
> you can do this using the following context parameter (which sets it to
> 64KB, you may
> if necessary need to adjust it to the size of the largest HTML output
> you have):
>
> <context-param>
> <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
> <param-value>65535</param-value>
> </context-param>
>
> Setting to 800KB, since /orders/pf_Add.xhtml (640+ KB) is the largest
> view;
> if this is not set, then OmniFaces 1.2 (OmniPartialViewContext) breaks
> pf_BrowsePayroll.xhtml,
> see OmniFaces issue 73 (URL above)
> <context-param>
> <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
> <param-value>819200</param-value>
> </context-param>
> -->
> <context-param>
> <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
> <param-value>65535</param-value>
> </context-param>
>
Re: Help with java.lang.IllegalStateException: Cannot change buffer
size after data has been written
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel <fk...@gmail.com> wrote:
> Not sure if this is this a MyFaces issue, but as I don't remember having it
> when my projects were running with with Mojarra, I'd like to see if you can
> help me.
>
> I'm eventually seeing this exception in my Tomcat 7.0.47 log:
>
> java.lang.IllegalStateException: Cannot change buffer size after data
> has been written
> at
> org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:254)
>
Felipe,
I think I saw that error long time ago and I discussed with BalusC on/via
OmniFaces google-code project's issue tracker.
anyway, I think it was caused by the largest XHTML page in my app, which
has hundreds of UI components (<input/>, etc...).
Below, is what I saved in my web.xml per that discussion with BalusC.
<!--
http://code.google.com/p/omnifaces/issues/detail?id=73
Comment 25 by project member balusc, Today (11 minutes ago)
Just keep GZIP filter threshold size default. It has not the same
meaning as Facelets buffer size.
A large Facelets buffer size may be useful during development, to spot
any bugs in the view which causes exceptions during render response. But I
would not set it that large in production.
http://code.google.com/p/omnifaces/issues/detail?id=51
It's technically not possible to change the response when it has
already been committed.
So if an exception occurs during rendering the response and the
response has already been committed,
then you'll end up with a broken response. In most default
servletcontainer/webapp configurations,
the response get committed when 2KB has already been written to the
response.
One of the ways to avoid this is to increase the response buffer size.
In Facelets,
you can do this using the following context parameter (which sets it to
64KB, you may
if necessary need to adjust it to the size of the largest HTML output
you have):
<context-param>
<param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
<param-value>65535</param-value>
</context-param>
Setting to 800KB, since /orders/pf_Add.xhtml (640+ KB) is the largest
view;
if this is not set, then OmniFaces 1.2 (OmniPartialViewContext) breaks
pf_BrowsePayroll.xhtml,
see OmniFaces issue 73 (URL above)
<context-param>
<param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
<param-value>819200</param-value>
</context-param>
-->
<context-param>
<param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
<param-value>65535</param-value>
</context-param>