One other item. I've been working under the assumption that you're
using JSP for your view layer.
If you're using facelets, than the responseBufferSize parameter isn't
relevant.
Also, the algorithm of of not buffering until state is required to be
written holds true if using Facelets.
In fact, we borrowed that optimization from them.
Mikael Andersson wrote:
> Another question.
>
> If I use the myfaces extension filter and jsf ri 1.2, will that mean
> that the page content gets cached twice (with a for at the very top of
> the page)?
>
> Thanks,
> Mike
>
> On 21/09/2007, *Ryan Lubke* <Ryan.Lubke_at_sun.com
> <mailto:Ryan.Lubke_at_sun.com>> wrote:
>
> Mikael Andersson wrote:
> > Hi Ryan
> >
> > I'm using 1.2_04, when is a state marker typically written?
> By default, the marker will be written right *before* the form tag is
> closed.
> So all of the content prior to that will not be buffered by the RI.
>
> >
> > And what is it? Is it a place holder for which is replaced with the
> > component tree state in the rendered output?
> It's an implementation specific string that the ViewHandler will look
> for after the rendering of the component
> tree is complete. For each occurrence of this string, the actual
> result
> from the StateManager will be inserted.
> >
> >
> > Can you provide hints of how to configure 1.2_04 to manage pages
> with
> > a lot of content? Which buffer sizes are sane to use? Asking becuase
> > of the post below suggesting small buffer size.
> It really depends on the view. If you keep to having one form per
> page
> and you generally don't have a lot of content after the form, the
> default (I don't have the code handy, but I think it's 1024) should be
> sufficient. If you have multiple forms per page, then all of the
> content after the first form will be buffered, so depeneding on how
> large the other forms are you may see a need to increase the buffer
> size (I believe the param is com.sun.faces.responseBufferSize - I'll
> follow up with another email if the param and default aren't what I'm
> remembering)
>
> >
> > Many thanks,
> > Mike
> >
> > On 18/09/2007, *Ryan Lubke* < Ryan.Lubke_at_sun.com
> <mailto:Ryan.Lubke_at_sun.com>
> > <mailto:Ryan.Lubke_at_sun.com <mailto:Ryan.Lubke_at_sun.com>>> wrote:
> >
> > It depends on the version.
> >
> > If you're using 1.2_04 or later, the response won't be buffered
> > until a
> > state marker has been written. At that point buffering
> > begins in order to support writing the state after the the
> > rendering of
> > the component tree has completed.
> >
> >
> >
> > Gurkan Erdogdu wrote:
> > > JSF 1.2 RI uses buffering I think and use context
> parameter to size
> > > buffering name as *'com.sun.faces.responseBufferSize* '
> > >
> > > ----- Original Message ----
> > > From: Mikael Andersson <mail.micke_at_gmail.com
> <mailto:mail.micke_at_gmail.com>
> > <mailto: mail.micke_at_gmail.com <mailto:mail.micke_at_gmail.com>>>
> > > To: users_at_javaserverfaces.dev.java.net
> <mailto:users_at_javaserverfaces.dev.java.net>
> > <mailto:users_at_javaserverfaces.dev.java.net
> <mailto:users_at_javaserverfaces.dev.java.net>>
> > > Sent: Tuesday, September 18, 2007 10:52:40 AM
> > > Subject: Is rendered output buffered or streamed?
> > >
> > > Hi
> > >
> > > I wonder if JSF 1.2 RI is buffering the rendered output,
> or if it is
> > > streaming it back to the browser?
> > >
> > > Asking because I had an issue a while ago with the the myfaces
> > > extension filter which buffered everything before writing the
> > response
> > > to the client, which caused memory problems when rendering a
> > lot of
> > > data.
> > >
> > > Many thanks,
> > > Mike
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > > Shape Yahoo! in your own image. Join our Network Research
> Panel
> > today!
> > >
> >
> <http://us.rd.yahoo.com/evt=48517/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
> <http://us.rd.yahoo.com/evt=48517/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7>>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > users-unsubscribe_at_javaserverfaces.dev.java.net
> <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net>
> > <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net
> <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net>>
> > For additional commands, e-mail:
> > users-help_at_javaserverfaces.dev.java.net
> <mailto:users-help_at_javaserverfaces.dev.java.net>
> > <mailto:users-help_at_javaserverfaces.dev.java.net
> <mailto:users-help_at_javaserverfaces.dev.java.net>>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_javaserverfaces.dev.java.net
> <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net>
> For additional commands, e-mail:
> users-help_at_javaserverfaces.dev.java.net
> <mailto:users-help_at_javaserverfaces.dev.java.net>
>
>