Re: Help with java.lang.IllegalStateException: Cannot change buffer size after data has been written
The 64K buffer didn't worked. Any other idea? Thanks 2014-07-16 11:33 GMT-03:00 Howard W. Smith, Jr. smithh032...@gmail.com: On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel fkjae...@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-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value65535/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-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value819200/param-value /context-param -- context-param param-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value65535/param-value /context-param
Re: Help with java.lang.IllegalStateException: Cannot change buffer size after data has been written
how large is your page? maybe you need a larger buffer. On Thu, Jul 24, 2014 at 3:39 PM, Felipe Jaekel fkjae...@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. smithh032...@gmail.com: On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel fkjae...@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-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value65535/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-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value819200/param-value /context-param -- context-param param-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value65535/param-value /context-param
