Discussions

News: Differences between client-side and server-side state for JSF

  1. The Glassfish Wiki has a new FAQ posted, with the subject title "What are the differences between Server and Client side state saving and what are the benefits/drawbacks of each?" Both are easy to use, being a simple parameter in web.xml, but the implications of them aren't always clear. This FAQ tries to summarize the two methods (plus the effect of client-side compression) for the JSF RI, bundled with Glassfish. The short summary is that client-side state, plus compression, is probably the way to go - based on the FAQ. Client-side is shown to use low bandwidth, and low server memory. However, it uses more CPU; your mileage may vary. Every state method has a cost, so your application and installation may be able to cope with one method over the others in different ways. State saving is one of the better features of JSF, as well as being fairly poorly understood. It's the reason for the JSF lifecycle; one of the early stages of the JSF lifecycle is rebuilding the component tree based on state. The FAQ doesn't analyze state as a runtime effect very clearly, however. It says that server state has a high RAM cost, but doesn't say how much the client-side state saves; after all, client-side state doesn't avoid the component model being on the server, but only means that it's not preserved on the server past an individual request. What do you think? What are your observations of JSF memory, CPU, and bandwidth usage? What about other frameworks?

    Threaded Messages (31)

  2. The FAQ actually mentions that client side state saving has higher bandwidth req. (medium for compressed and high for uncompressed), as well as CPU req. It is harder to scale the bandwidth and CPU than the server memory. This being said it actually depends on the complexity of the saved views.
  3. Rebuild State versus Keep them[ Go to top ]

    So, client-side state management is good because it uses less memory in the server side, right? As the article says: it uses more CPU. But what about the objects that are created when the state must be "recovered" from client-side, until the server outputs the view? They are in Server's RAM. Now, imagine a LOT of users, accessing your system and rebuilding states everytime during its use. Will the occupied RAM decreases just because the state is on client-side? I don't think so. But yes, the CPU usage _plus_ memory usage will increase because of states been recovered on every request, _plus_ Garbage Collections, _plus_ Objects construction time, and more... I will stick with Wicket and it's server-side state management, ant it's low cpu usage. (Hey, I know JSF does server-side state management... Its just that, its not 100%) []'s miojo
  4. Re: Rebuild State versus Keep them[ Go to top ]

    I will stick with Wicket and it's server-side state management, ant it's low cpu usage. (Hey, I know JSF does server-side state management... Its just that, its not 100%)

    []'s
    miojo
    I'm not an expert on the RI state-saving code -- I've not spent much time at all in that code beyond code reviews. It is my understanding, though, that, when using server-side state saving, the only "state" sent to the client is the key the server will need to look up the state on the server side, so the state is all on the server. I'm certainly open to correction, though.
  5. Re: Rebuild State versus Keep them[ Go to top ]

    Right.
  6. Re: Rebuild State versus Keep them[ Go to top ]

    Actually if you keep the state Server Side, all the views corresponding to all open sessions are in the server's memory. If instead you keep the state in the client only the views being currently needed to process requests are in the servers sessions. In a typical scenario the number of current requests being processed is much lower than the number of open Sessions.
  7. Re: Rebuild State versus Keep them[ Go to top ]

    Actually if you keep the state Server Side, all the views corresponding to all open sessions are in the server's memory. If instead you keep the state in the client only the views being currently needed to process requests are in the servers sessions.
    In a typical scenario the number of current requests being processed is much lower than the number of open Sessions.
    oops "...process requests are in the server's ram" :)
  8. Glass Fish View State[ Go to top ]

    Looking at the link provided in initial thead I see that the number of views in a session defaults to 15. This confirmed my statement that glassfish now put this token in your HTML page that links the post back to the corrent component tree from which it was corrected. I think this is a hugh technical point for JSF 1.2, interesting to me anyway.
    Actually if you keep the state Server Side, all the views corresponding to all open sessions are in the server's memory. If instead you keep the state in the client only the views being currently needed to process requests are in the servers sessions. In a typical scenario the number of current requests being processed is much lower than the number of open Sessions.
    This is a good point but one has to think about building wizards and such. If I have a wizard that has previous and next, it is nice to have a "cached" version of the view to go back too. JSF will not initialize a new view tree but re-select the old view tree saving both time and state and helps out with the nasty back-button problem. This has some significant design benefits (and traps) that would be completely lost with client side state saving. It also helps solve the multi-brower issue. May not be an issue for most but I have encountered the requirement and it was almost impossible to solve for JSF 1.1. I am still reading the details of the original post. On the other hand I agree that if you push view state to the client then you are basically off-loading your server memory requirements onto the client boxes. In the end this comes down to trade-offs between functionality, performance, and cost of resources (server).
  9. Security considerations[ Go to top ]

    I ran into an interesting security issue using JSF client-side state saving. Suppose you have simple form with a couple of text fields and a command button. Over time, you discover that link spammers are using your form to promote a pharmacopeia of male enhancement drugs. Being the vigorous Java developer that you are, you decide to add a security component to your form, such as Seam's CAPTCHA implementation, to prevent the advertisement of these superfluous medicines. The link spammers are wily; they don't sit around hitting the submit button each time they want your business. Rather, they have some automated tools that schedule and submit an offline copy of your web page. Now, what happens when the link spammers post an older version of your form, i.e. a snapshot of the view before you added the security component? If you used client-side state saving, the UI component tree was saved along with the HTML, so the link spammer's form submission does not contain the recently added security component! The net result is that, due to client-side state saving, the spammer can now bypass your CAPTCHA security component. I would switch to server-side state saving for security purposes, but some frameworks require client-side state saving.
  10. The table wasn't meant to be much more than a very loose example of what to expect with those data points. How much memory/cpu will be used, as posted earlier, will depend on the view complexity. On the topic of security, I left one configuration option pertaining to the encryption of client state. I will add that to the wiki today.
  11. Re: Security[ Go to top ]

    On the topic of security, I left one configuration option pertaining to the encryption of client state. I will add that to the wiki today.
    Hi Ryan, Encrypting client state still leaves applications vulnerable to the issue I described. Perhaps an effective solution would be to expire the view state somehow, eg. if the HTTP session associated with the incoming state has expired, throw a servlet exception. I'm sure a date/time token could be added to the encoded view state to track when the view was serialized. Applications could control this via web.xml, for example by specifying the maximum age of the view state before it is considered invalid by the server in way that is similar to how browsers handle expired cookies and digital certificates. Ian
  12. Re: Security[ Go to top ]

    On the topic of security, I left one configuration option pertaining to the encryption of client state. I will add that to the wiki today.

    Hi Ryan,

    Encrypting client state still leaves applications vulnerable to the issue I described.

    Perhaps an effective solution would be to expire the view state somehow, eg. if the HTTP session associated with the incoming state has expired, throw a servlet exception.

    I'm sure a date/time token could be added to the encoded view state to track when the view was serialized.

    Applications could control this via web.xml, for example by specifying the maximum age of the view state before it is considered invalid by the server in way that is similar to how browsers handle expired cookies and digital certificates.

    Ian
    Hi Ian, I've captured your original post and possible solution to the issue here: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=612 Thanks!
  13. Re: Security[ Go to top ]

    Ryan Lubke: Hi Ian,

    I've captured your original post and possible solution to the issue here: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=612

    Thanks!
    Thanks Ryan. I posted a similar bug report on the Seam JIRA a while back but it was unproductive. http://jira.jboss.com/jira/browse/JBSEAM-1137 Hopefully your bug report will lead to some enhancements to JSF security.
    n n: I think you are overlooking the fact that it is the data that is getting stored on the client and not the code. Whenever your button handler went to look for the captcha value it wouldn't be there and it would be up to you to do whatever error handling you would do.
    It is most certainly the stale UI component tree stored in client-side state that is at fault. Take a look at the Seam CAPTCHA component. It uses a validator to check user input. If the user enters the wrong value, validation fails and the update model values / invoke application phases are not fired. In my case, the user was submitting an earlier version of my view that did not have this component in the tree, therefore no such validation logic was called, even though the current version of that page on the server had the CAPTCHA validator installed. Because of this, the CAPTCHA validator was surprisingly easy to circumvent. Best regards, Ian
  14. Re: Security[ Go to top ]

    To me, this would be a bug in the reserialization of client state in the JSF implementation. The server should still maintain the most current component tree. If reserialization doesn't include values for all current components this should raise a flag. Have you tried JSF providers other than MyFaces? I don't know what the spec says to do in this regard.
  15. Re: Security[ Go to top ]

    To me, this would be a bug in the reserialization of client state in the JSF implementation. The server should still maintain the most current component tree. If reserialization doesn't include values for all current components this should raise a flag.

    Have you tried JSF providers other than MyFaces? I don't know what the spec says to do in this regard.
    I agree Jim, it sounds like an unmarshalling problem on the server side. We just switched from MyFaces 1.1.4 to JSF-RI 1.2, so hopefully this issue has been (or will be) resolved.
  16. Re: Security[ Go to top ]

    The server should still maintain the most current component tree.
    Interesting... why would you store the current component tree on the server when using client state saving? Isn't the whole point of client state saving that you don't have to use session affinity and thus have more options in how you organize your cluster and that you can better recover from session expiry - potentially at least?
  17. Re: Security[ Go to top ]

    Thanks Ryan.

    I posted a similar bug report on the Seam JIRA a while back but it was unproductive.

    http://jira.jboss.com/jira/browse/JBSEAM-1137

    Hopefully your bug report will lead to some enhancements to JSF security.
    Hi Ian, Just a quick follow up, we've implemented the fix to optionally timeout client view state and will be released as part of 1.2_05.
  18. Re: Security[ Go to top ]

    Just a quick follow up, we've implemented the fix to optionally timeout client view state and will be released as part of 1.2_05.
    Ryan is da man. Seriously, i'v never seen any project implement fixes/features consistently as quickly as RI 1.2 does. Keep up the great work! /Henri Karapuu
  19. Re: Security[ Go to top ]

    Hi Ian,

    Just a quick follow up, we've implemented the fix to optionally timeout client view state and will be released as part of 1.2_05.
    Wow! That's great. Thanks Ryan!
  20. Re: Security[ Go to top ]

    Hi Ian,

    Just a quick follow up, we've implemented the fix to optionally timeout client view state and will be released as part of 1.2_05.
    Hi Ryan, What happens if the view state being checked does not include the creation time information (eg. it was created before JSF-RI 1.2_05, as in my use case)? Will JSF-RI 1.2_05 treat the view state as though it had expired in this case? Thanks, Ian
  21. Re: Security[ Go to top ]


    Hi Ryan,

    What happens if the view state being checked does not include the creation time information (eg. it was created before JSF-RI 1.2_05, as in my use case)?

    Will JSF-RI 1.2_05 treat the view state as though it had expired in this case?

    Thanks,
    Ian
    If the timeout option is enabled, and the marker isn't present, yes, it will.
  22. Re: Security[ Go to top ]


    Hi Ryan,

    Encrypting client state still leaves applications vulnerable to the issue I described.

    Perhaps an effective solution would be to expire the view state somehow, eg. if the HTTP session associated with the incoming state has expired, throw a servlet exception.

    I'm sure a date/time token could be added to the encoded view state to track when the view was serialized.

    Applications could control this via web.xml, for example by specifying the maximum age of the view state before it is considered invalid by the server in way that is similar to how browsers handle expired cookies and digital certificates.

    Ian
    I think you are overlooking the fact that it is the data that is getting stored on the client and not the code. Whenever your button handler went to look for the captcha value it wouldn't be there and it would be up to you to do whatever error handling you would do. The security real issue is if the client can manipulate the state by changing your captcha control's expected value to be the same as the passed in value. The other guy covered that with the encryption option. I'm sure that it isn't a 100% fool proof option but it raises the barrier to something not worth while for the spammer. Ohh the resources we waste on those low lifes. Can we get some kind of international carbon tax passed against these guys? Maybe throw in some kind of provision for making them participate in a bloodsport? I'd pay $49.95 on pay-per view for that!
  23. Let's define state[ Go to top ]

    I assume that we are talking about the JSF View State (component tree); not HTTP session state (and any managed objects that might be stored there), or conversational state if I can use that term loosely to describe persisted information that is longer than a request but shorter than a session. My point here is that for any given application the actual amount of information that needs to be "saved" can vary considerably and JSF view state may only be a small percentage. The main reason that I have heard for using client side rather than server side state saving has to do with a clustered environment. If you cannot pin your requests to a particular server, the over-head of moving the JSF view state from server to server can be costly when using server side state saving. Client side state saving eliminates this issue all together. The other reason I have heard for using client side saving is that in JSF 1.1 you could not easily support multiple browser instances, especially when they were using the same view. This problem (based on my recent use of 1.2 and glassfish) has actually been solved because JSF is now storing a token on the client that uniquely identifies the server side view state associated with an HTML page. As an observation, the default state saving mechanism in JSF is server-side while the default state saving mechanism in .NET is client-side. Not sure why JSF decided on server-side while .NET decided on client-side, this would be an interesting comparsion for this discussion. This issue is not unique to JSF for those thinking it might be a design issue or something truly unique to JSF. Finally, server side state saving is pluggable and I would love to see a server vendor come out with a mechanism to cache server side state so as to do a better job managing it's memory footprint.
  24. Re: Let's define state[ Go to top ]

    The main reason that I have heard for using client side rather than server side state saving has to do with a clustered environment. If you cannot pin your requests to a particular server, the over-head of moving the JSF view state from server to server can be costly when using server side state saving. Client side state saving eliminates this issue all together.
    Basically true, but most any cluster can 'pin request to particular server' (sticky sessions), the problem is more about session replication needed for failover.
    Finally, server side state saving is pluggable and I would love to see a server vendor come out with a mechanism to cache server side state so as to do a better job managing it's memory footprint.
    Could you elaborate what you mean with the caching? I'm just starting work towards improved JSF state saving (annotation for marking fields to be saved, not saving values that are defaults, and perhaps saving only deltas). If you have state saving related ideas i'd be very interested in hearing them.. /Henri Karapuu
  25. JSF State Saving[ Go to top ]

    Could you elaborate what you mean with the caching? I'm just starting work towards improved JSF state saving (annotation for marking fields to be saved, not saving values that are defaults, and perhaps saving only deltas). If you have state saving related ideas i'd be very interested in hearing them..
    Well I have implemented and been working on (concept)state saving mechanism based on cache (think JSR-107) rather than java persistence. My issue with JBoss SEAM and Apache Orchestra conversational state is that they are based on Java persistence while I feel like this is better suited to a java caching solution. To that end I have an implementation for state saving based on EHCACHE. Back to this thread, the initial link which everyone should look at if they have not, points to a good explaination of the new view state mechanism in glass-fish which I only discovered by accident when doing my above caching implementation. The sum of all this is that I think both the view state and JSF View Controllers (aka managed beans) all belong in a cached context. My solution makes sures that when a session terminates so do the views and managed beans, it allows you to set time-outs associated with "conversations", and would support a distributed cache solution when desired. For me, java persistence belongs in the business layer. I would love to discuss my thoughts on this with anyone ...
  26. Re: JSF State Saving[ Go to top ]

    My issue with JBoss SEAM and Apache Orchestra conversational state is that they are based on Java persistence while I feel like this is better suited to a java caching solution.
    I have to admit, i don't understand at all what you mean.. Are you refering to JPA or Serialization when you say 'Java persistence'?
    The sum of all this is that I think both the view state and JSF View Controllers (aka managed beans) all belong in a cached context. My solution makes sures that when a session terminates so do the views and managed beans
    But, what difference does it make if you save view state and managed bean within session, or to some external cache? /Henri Karapuu
  27. Re: JSF State Saving[ Go to top ]

    I have to admit, i don't understand at all what you mean.. Are you refering to JPA or Serialization when you say 'Java persistence'?
    Sorry for lack of clarity, I am refering to JPA when I say java persistence. Serialization however IS a requirement of java caching since it acts on java objects but is NOT a requirement of JPA.
    But, what difference does it make if you save view state and managed bean within session, or to some external cache?
    First if you store a managed bean in session it is not serialized with respect to client side saving so I want to be clear about that point. Client side saving includes the view state component tree, and the components state (listeners, converters, etc). For simple web sites and such I don't think it makes much of a difference and most of us using JSF would agree that putting managed beans into the user session (along with view state) is a workable solution. However, for complex applications I don't think this scales very well. Thus the question of this thread is the use of the HTTPSession map for state saving associated with large enterprise applications. One solution, presented in this thread, is to move the view-state to the client. This in effect moves "part" of the problem to the client. The only concern is the server CPU overhead with the serialization (compressed and/or uncompressed) and communication bandwith associated with the solution. I pointed out that there are also some functionality you might be losing as well. The use of "User Session" for state-saving data is pretty coarse. From a server perspective, if you are running in a cluster and/or require fail over the "User Session" is one big serialized blob of data that needs to be managed. Servers have been optimized for the but it is still not a very efficient mechanism. On any given server, if you have lots of users it is not necessarily true that you are keeping ALL of that session state in server memory. With most modern servers, you are either keeping it in memory or storing it somewhere (disk). When a request comes in, these blobs must be either move into or out of memory. The server has no idea how much of that session state is actually required to process the request and as such has to treat it atomicly. Lots of users can result in lots of churn. Now caching is a bit more fine grained. If I get in a request I do not necessarily have to move in every view state representation and every managed bean (scope > request) into server memory to service the request. All I really want to do is grab the view-state tree associated with the request and any managed beans required to process the request. Given a large number of users, a cached solution will do a far better job at managing both server memory and resources then the out of the box coarse grained HTTP Session. JSF, as its opponents will always raise, will place a significant load on your server due to the view-state requirement and to that I would also add the session scope (transactional persistence) requirement. The cached solution I have implemented solves this problems and also brings in a lot more flexibility into how you can save both the view state and any session or conversational bean you have into a cache. These objects can then be managed much more efficiently by the cache manager, reducing the load on the server, while still retaining clustering and fail-over capabilities associated with the JSF solution.
  28. Re: JSF State Saving[ Go to top ]

    My issue with JBoss SEAM and Apache Orchestra conversational state is that they are based on Java persistence while I feel like this is better suited to a java caching solution.
    I have to admit, i don't understand at all what you mean.. Are you refering to JPA or Serialization when you say 'Java persistence'?
    Sorry for lack of clarity, I am refering to JPA when I say java persistence.
    Then, i think i understand you even less :) AFAIK both Seam and Orchestra save the conversational state in session, and have nothing (directly) to do with JPA. What exactly you mean here by saying 'they are based on Java persistence'?
    From a server perspective, if you are running in a cluster and/or require fail over the "User Session" is one big serialized blob of data that needs to be managed. Servers have been optimized for the but it is still not a very efficient mechanism.
    From what i'v gathered, it seems to me that (modern) cluster solutions replicate the state by sending deltas of the sessions. Have you run any performance tests to measure the difference between session replication and EHCache based solutions?
    With most modern servers, you are either keeping it in memory or storing it somewhere (disk). When a request comes in, these blobs must be either move into or out of memory. ... Now caching is a bit more fine grained. If I get in a request I do not necessarily have to move in every view state representation and every managed bean (scope > request) into server memory to service the request.
    Yes, thats a good point. I was thinking about this actually some time ago, but didn't get further from thinking. Some of my thoughts from that time were: - how about if letting the container keep all sessions in memory, and then letting OS level VM management take care of swapping them out to disk when necessary. This should mean that the sessions don't have to swapped in/out of memory as big atomic units. - other than container's own clustering solutions might prove better for session replication (terracotta etc.). If performance tests prove real benefit on your approach i'd be definitely interested in giving it a try. Have you considered releasing your work on this publicly? /Henri Karapuu
  29. Re: JSF State Saving[ Go to top ]

    Then, I think I understand you even less :) AFAIK both Seam and Orchestra save the conversational state in session, and have nothing (directly) to do with JPA. What exactly you mean here by saying 'they are based on Java persistence'?
    Both Seam and Orchestra save conversational state associated with a user's session but not in the HTTPSession map. Both hook into Managed Bean facility to create objects that are ultimately persisted using JPA. It is true that they have nothing directly to do with JPA but that is the storage (implementation) mechanism they use. To me JPA is over-kill and they are re-using the wrong mechanism, this requires a cache solution.
    how about if letting the container keep all sessions in memory, and then letting OS level VM management take care of swapping them out to disk when necessary. This should mean that the sessions don't have to swapped in/out of memory as big atomic units. - other than container's own clustering solutions might prove better for session replication (terracotta etc.).
    We are a bit off-topic now but the cache solution actually involves a container(context) concept where a JSF application has 4 cached scopes (Session, Conversation, View, and Region). My feeling is that a JSF View should never value bind directly to the business layer and should always use a passive controller. Controller implementations should be cached. The business model is accessed only by the passive controller never the view components. Thus in any JSF application you end up with Sesson Controllers, Conversational Controllers, View Controllers, and Region Controllers. Controllers are cached POJO's. They access the business layer using Spring or what ever other mechanism the developer needs. Often controllers will have the form data as part of the controller. Now if you cache these controller managed beans together with the view-state you can support very rich applications having reusable view parts and controllers. The emphasis is that View state (both controller state and component tree state) are maintained server side, light weight, cached, scalable, and most importantly separate of business domain and logic.
  30. Re: JSF State Saving[ Go to top ]

    Then, I think I understand you even less :) AFAIK both Seam and Orchestra save the conversational state in session, and have nothing (directly) to do with JPA. What exactly you mean here by saying 'they are based on Java persistence'?
    Both Seam and Orchestra save conversational state associated with a user's session but not in the HTTPSession map. Both hook into Managed Bean facility to create objects that are ultimately persisted using JPA. It is true that they have nothing directly to do with JPA but that is the storage (implementation) mechanism they use. To me JPA is over-kill and they are re-using the wrong mechanism, this requires a cache solution.
    This is definitely not true. Seam "persists" conversation state in the HttpSession.
  31. Re: JSF State Saving[ Go to top ]

    This is definitely not true. Seam "persists" conversation state in the HttpSession.
    I will retract my statement about where Seam stores conversational context since I am not a Seam expert. I will say was (still am) confused about the documentation. If a conversation is a persisted context and a persisted context uses an Entity Manager then are we not discussing JPA? But then I found, re-looking at documentation, there was different state store strategy for each context and went on to imply HTTPSession for conversational state. The I also read there is a Conversation-scope PC (Persistence Context) so as you say there is almost too much there to digest in Seam. Not sure why I am not using it since I think for JSF the solution is far more comprehensive and Spring has no “affinity” for JSF. If Seam does store conversational state in HTTPSession then it still has all problems associated with clustering and the documentation says it does not so I need to dig some more or someone needs to clarify.
  32. Re: JSF State Saving[ Go to top ]

    Both hook into Managed Bean facility to create objects that are ultimately persisted using JPA.
    Well that explains why i couldn't understand what you meant -- as Gavin said what you state is simply not true ..
    My feeling is that a JSF View should never value bind directly to the business layer and should always use a passive controller. Controller implementations should be cached. The business model is accessed only by the passive controller never the view components. Thus in any JSF application you end up with Sesson Controllers, Conversational Controllers, View Controllers, and Region Controllers. Controllers are cached POJO's.
    There is so much custom terminology and the subject is so broad that it's difficult to follow your thoughts based on a short description. However, it's a very interesting subject and i think comparing and studying approaches used by other developers is time well spent (if you blog or write an article about this i'd be definitely interested reading more). /Henri Karapuu