myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: Help with java.lang.IllegalStateException: Cannot change buffer size after data has been written
Date Thu, 24 Jul 2014 19:44:09 GMT
how large is your page? maybe you need a larger buffer.



On Thu, Jul 24, 2014 at 3:39 PM, Felipe Jaekel <fkjaekel@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. <smithh032772@gmail.com>:
>
> > On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel <fkjaekel@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>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message