Web Flow Ignores STATE_SAVING_METHOD_CLIENT for JSF Views?

[Peter Gibbons]

I have a web app that is using Spring Web Flows with Facelets as the view technology. I have set the context param

<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>

But I was noticing that my Session Sizes were getting quite large. Upon further investigation I realized that the FlowViewStateManager was holding extremely large references to objects. When I look at the code for this class I see the following method

public boolean isSavingStateInClient(FacesContext context) {
if (!JsfUtils.isFlowRequest()) {
return delegate.isSavingStateInClient(context);
} else {
return false;
}
}

So it appears like Web Flow will save the state server side regardless of the context param if the request is a flow request. What is the reasoning behind this, and is there anyway I can store the state client side with Web Flow?

Thank you.

[Peter Gibbons]

It seems that you have no option in this case, and in light of this realization I would say that these two are a completely inappropriate combination of technologies to use for a web app, and I will have to start moving away from Spring Web Flows. It's a shame that this behaviour isn't documented.

[dummymael]

Hi Peter,

I am having a similar problem to you.. but in my case, I am seeing multiple instances of the view state in the session. If only there were only one instance maintained and would just discard previous views, I believe that would be a great alternative.

Also, isn't server side state saving method a lot more efficient? e.g. no serialization, lesser bandwidth since client won't have to send entire state back to server..

Just some thoughts.

Cheers,
Darth

[Peter Gibbons]

Hi Darth,

If you are seeing multiple instances of Views, I think this can be tuned using the max-execution-snapshots attribute on the flow-executor element in your web flow config file. If you set this to 0, then it appears to only ever keep 1 Snapshot around for each execution, and these Snapshots are where those Views are stored. At least that's the behaviour I've been seeing.

What is more efficient between client state saving and server side saving I suppose depends on what you have more of an abundance of, and how your application is used. In my case, I'd rather make the trade off of bandwidth/render for memory, but it depends totally on the situation.

Hope this helps.

[dummymael]

Hi Peter,

Thanks for the tip.

I am seeing multiple instances of the UIViewRoot when I do a memory heap dump, but one thing I've noticed is that all of them except 1 had a source of "org.springframework.webflow.execution.Event". Shouldn't events be discarded when the case of snapshots set to 0, e.g. I don't need to backtrack so no point of keeping them there.

Back to the topic of setting state saving to client method, I agree with you in that currently there is no way for setting it as such, as SWF will always store the state on the server. Maybe we can create a defect for this and get some visibility.

Cheers,
Darth

[Peter Gibbons]

Are they part of the same or separate executions? I haven't seen this exact scenario, but I'll offer a guess.... Perhaps you have your max-executions set too high, or the default is 5, so perhaps it is using that. If you truly want minimal "remembering" of the flow state then you need to set max-executions to 1 and max-execution-snapshots to 0. This *should* keep around just 1 execution with 1 snapshot and discard each time you move around (I say should because spring often surprises me with its behaviour).

The 1 snapshot needs to be there for JSF sake, the state has to be somewhere.

I'd be interested to know if this helps for you... I really wish there was more support on these boards from the experts...

[dummymael]

Are they part of the same or separate executions? I haven't seen this exact scenario, but I'll offer a guess.... Perhaps you have your max-executions set too high, or the default is 5, so perhaps it is using that. If you truly want minimal "remembering" of the flow state then you need to set max-executions to 1 and max-execution-snapshots to 0. This *should* keep around just 1 execution with 1 snapshot and discard each time you move around (I say should because spring often surprises me with its behaviour).

I've only used the default for max-executions which is 5. But I can't set it to 1 or else there will only be 1 conversation per user session, I need to support multiple tabs in one browser (at least, thats what the SWF doc says about this property.) What puzzles me though is the number of events instantiated with the UIViewRoot as its payload. After looking around and doing some more heap dumps, I can find that the number of view instances are the same with the number of RequestControlContextImpl there are. I'm guessing that RequestControlContextImpl would be GC'ed sooner or later, but not immediately.