Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of smithh032772@gmail.com
 designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALPFNG9uC6HMNqQn4W1dRCi=PvpX9-0rFooPeVhca+PwjfpggA@mail.gmail.com>
References: 
 <CALPFNG9uC6HMNqQn4W1dRCi=PvpX9-0rFooPeVhca+PwjfpggA@mail.gmail.com>
Date: Wed, 16 Jul 2014 10:33:49 -0400
Message-ID: 
 <CAGV1rDJuWxeziRn2qVccJkKSNxCkFA94MfZ+JVNLAvUTTvRCQg@mail.gmail.com>
Subject: Re: Help with java.lang.IllegalStateException: Cannot change buffer
 size after data has been written
From: "Howard W. Smith, Jr." <smithh032772@gmail.com>
To: MyFaces Discussion <users@myfaces.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a83e0a12a6904fe5069f4

--047d7b3a83e0a12a6904fe5069f4
Content-Type: text/plain; charset=UTF-8

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>

--047d7b3a83e0a12a6904fe5069f4--