myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felipe Jaekel <fkjae...@gmail.com>
Subject Re: Help with java.lang.IllegalStateException: Cannot change buffer size after data has been written
Date Thu, 24 Jul 2014 19:39:41 GMT
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