MyFaces Core
  1. MyFaces Core
  2. MYFACES-3779

Mixed mode(Server+client) for state saving

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) & after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data & now it will be kept on client side, now the client & the server both know that state for this session is there on client. If the page has died & no request has been sent to server asking for state data till that period of time, then state data would be removed from server.

      A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode.

      Such mixed modes would be very helpful in improving performance, & better utilization of the server resources.

        Activity

        Hide
        Mike Kienenberger added a comment -

        This is a great discussion. Why not move it to the dev or users mailing list where other people will participate in it?

        Show
        Mike Kienenberger added a comment - This is a great discussion. Why not move it to the dev or users mailing list where other people will participate in it?
        Hide
        Leonardo Uribe added a comment -

        Precisely the point is the weight of all actives jsf views in the application is usually very small compared with the additional information stored into session. We can say in the most simple application (the booking application from the performance comparison) is about less than 20%, and in complex applications that difference becomes less and less because the key point is watch out all beans stored in session (view, conversation, flow, access, session). This is the reason why I'm saying "... it is required more information about the usefulness of the change proposed from performance perspective. ...".

        In my personal opinion, if I have to choose between server side (more bandwith - more cpu availability - less server memory) and client side (less bandwith - less cpu availability - more server memory) I would prefer server side, because it does not grow as fast as you can imagine, and the bandwidth/cpu tends to limit the overall throughput of the system more quickly (note that depends on the average session size we are talking about). The evidence gathered suggest these days first you reach the theoretical maximum number of concurrent clients than fill the available memory and get an OutOfMemoryException (it depends of what you have as hardware, of course). New evidence will be most welcomed.

        In any case, I would prefer a simpler approach, just something that you can say "... this view or this group of views should use client side state saving with these params, but this other group use server side with these params ...".

        But maybe the real problem is not in JSF, and what we need is something in the web server (Tomcat) to send the whole session to the client.

        Suggestions are welcome.

        Show
        Leonardo Uribe added a comment - Precisely the point is the weight of all actives jsf views in the application is usually very small compared with the additional information stored into session. We can say in the most simple application (the booking application from the performance comparison) is about less than 20%, and in complex applications that difference becomes less and less because the key point is watch out all beans stored in session (view, conversation, flow, access, session). This is the reason why I'm saying "... it is required more information about the usefulness of the change proposed from performance perspective. ...". In my personal opinion, if I have to choose between server side (more bandwith - more cpu availability - less server memory) and client side (less bandwith - less cpu availability - more server memory) I would prefer server side, because it does not grow as fast as you can imagine, and the bandwidth/cpu tends to limit the overall throughput of the system more quickly (note that depends on the average session size we are talking about). The evidence gathered suggest these days first you reach the theoretical maximum number of concurrent clients than fill the available memory and get an OutOfMemoryException (it depends of what you have as hardware, of course). New evidence will be most welcomed. In any case, I would prefer a simpler approach, just something that you can say "... this view or this group of views should use client side state saving with these params, but this other group use server side with these params ...". But maybe the real problem is not in JSF, and what we need is something in the web server (Tomcat) to send the whole session to the client. Suggestions are welcome.
        Hide
        Thomas Andraschko added a comment -

        Can i ask you how much users and memory do you have on one machine?
        AFAIR we had only ~2-10kb view state (from small to big and of course without viewscoped beans) for a view.
        With 1000 users, limited views to 20 for each user and a state of 10kb (10kb is really big for a average state size) -> the complete state would only take 200mb for all users.

        Show
        Thomas Andraschko added a comment - Can i ask you how much users and memory do you have on one machine? AFAIR we had only ~2-10kb view state (from small to big and of course without viewscoped beans) for a view. With 1000 users, limited views to 20 for each user and a state of 10kb (10kb is really big for a average state size) -> the complete state would only take 200mb for all users.
        Hide
        Ertio Lew added a comment -

        For doing this customization just two configurable parameters are needed, each of which may be set in the web.xml only. First is, ofcourse specifying the state saving as 'Mixedmode' (or anything similar). Second parameter, would be the time interval for which state be kept on server & after which server would remove that state (The client may request for this state, until this time interval, to be transferred to client incase it is still alive but idle).

        Incase we also support the 2nd enhancement that I suggested, to limit the memory quota for server state saving & after which client saving would be used, a 3rd param may be put in the web.xml specify the memory quota for server state saving. All parameters may be put in the web.xml itself without maintaining a separate config file.

        It is not that we are choosing between server/client saving depending on which view it is, but infact it is about how long has that view been idle so that it's state should be transferred to client or how much quota has been exhausted by all view state data stored on server so that for further views state is saved on client. It is like we are using controlled server state saving for all views & when we are out of quota or view is inactive for a long time we switch to client state saving for that view.

        The problem we are trying to solve here is both better performance & avoid ViewExpiredExceptions.

        Show
        Ertio Lew added a comment - For doing this customization just two configurable parameters are needed, each of which may be set in the web.xml only. First is, ofcourse specifying the state saving as 'Mixedmode' (or anything similar). Second parameter, would be the time interval for which state be kept on server & after which server would remove that state (The client may request for this state, until this time interval, to be transferred to client incase it is still alive but idle). Incase we also support the 2nd enhancement that I suggested, to limit the memory quota for server state saving & after which client saving would be used, a 3rd param may be put in the web.xml specify the memory quota for server state saving. All parameters may be put in the web.xml itself without maintaining a separate config file. It is not that we are choosing between server/client saving depending on which view it is, but infact it is about how long has that view been idle so that it's state should be transferred to client or how much quota has been exhausted by all view state data stored on server so that for further views state is saved on client. It is like we are using controlled server state saving for all views & when we are out of quota or view is inactive for a long time we switch to client state saving for that view. The problem we are trying to solve here is both better performance & avoid ViewExpiredExceptions.
        Hide
        Leonardo Uribe added a comment -

        I have already studied the effect of the encryption over performance and I can say it is proportional to the size of the state. Small state, small performance overhead. Server side increase server memory usage, but client side increase network overhead and CPU usage.

        I can see the logic behind this. The problem is we have not agreed how should be done this customization, and first of all which problem we are trying to solve: better performance or avoid ViewExpiredException.

        If the feature is for performance, decide which views should use client side or server side looks like something that should be decided at deployment time. Should we use some kind of extra xml file for it? maybe, and it has sense if we add in the future the view pool technique. But if the feature is to avoid ViewExpiredException, it means there is something we need to fix at the spec level, because the application developer should be able to decide that when he/she is writing the application code.

        Show
        Leonardo Uribe added a comment - I have already studied the effect of the encryption over performance and I can say it is proportional to the size of the state. Small state, small performance overhead. Server side increase server memory usage, but client side increase network overhead and CPU usage. I can see the logic behind this. The problem is we have not agreed how should be done this customization, and first of all which problem we are trying to solve: better performance or avoid ViewExpiredException. If the feature is for performance, decide which views should use client side or server side looks like something that should be decided at deployment time. Should we use some kind of extra xml file for it? maybe, and it has sense if we add in the future the view pool technique. But if the feature is to avoid ViewExpiredException, it means there is something we need to fix at the spec level, because the application developer should be able to decide that when he/she is writing the application code.
        Hide
        Ertio Lew added a comment - - edited

        To deal with ViewExpiredExceptions most of us are forced to use client side saving even when cost of state saving on server is minimal but when using the client side saving, there are associated CPU costs to encrypt/decrypt the state when transferring between client & server. With client side saving, there are a lot of hidden input fields for viewstate data containing large amount of texts which increase the page size considerably when pages are relatively small. Thus I just feel when we use client side saving we a loosing a bit of performance, so why not just opt for client side saving when it becomes real necessity & otherwise use server saving, as per above mixed mode strategy.

        I think dealing with ViewExpiredException is a necessity for almost all public facing applications & right now using client side saving is the only way to deal with this but it has its own issues(as described above), thus this mixed mode looks somewhat addressing these concerns.

        Show
        Ertio Lew added a comment - - edited To deal with ViewExpiredExceptions most of us are forced to use client side saving even when cost of state saving on server is minimal but when using the client side saving, there are associated CPU costs to encrypt/decrypt the state when transferring between client & server. With client side saving, there are a lot of hidden input fields for viewstate data containing large amount of texts which increase the page size considerably when pages are relatively small. Thus I just feel when we use client side saving we a loosing a bit of performance, so why not just opt for client side saving when it becomes real necessity & otherwise use server saving, as per above mixed mode strategy. I think dealing with ViewExpiredException is a necessity for almost all public facing applications & right now using client side saving is the only way to deal with this but it has its own issues(as described above), thus this mixed mode looks somewhat addressing these concerns.
        Hide
        Leonardo Uribe added a comment -

        TA>> I didn't know that ViewScoped beans will be always serialized to the session now.

        Yes, that how things are working now according to the new JSF 2.2 spec. Flow scope beans needs to be serialized in session too, even if both @ViewScoped and @FlowScoped are not marked as persistent capable. It is the only way to make these scopes work.

        TA>> What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException?

        The beans will silently be created again, and the context will be lost. The code is already in place, so you can try the latest snapshot.

        Show
        Leonardo Uribe added a comment - TA>> I didn't know that ViewScoped beans will be always serialized to the session now. Yes, that how things are working now according to the new JSF 2.2 spec. Flow scope beans needs to be serialized in session too, even if both @ViewScoped and @FlowScoped are not marked as persistent capable. It is the only way to make these scopes work. TA>> What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException? The beans will silently be created again, and the context will be lost. The code is already in place, so you can try the latest snapshot.
        Hide
        Thomas Andraschko added a comment -

        >> It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown.

        I didn't know that ViewScoped beans will be always serialized to the session now.
        What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException?

        Show
        Thomas Andraschko added a comment - >> It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown. I didn't know that ViewScoped beans will be always serialized to the session now. What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException?
        Hide
        Leonardo Uribe added a comment -

        In JSF 2.2, ViewScoped beans are stored in session, no matter if client side or server side state saving is used.

        The code we have right now in MyFaces Core is good enough to be extended. The problem is there is no clarity about the usefulness of the strategy proposed, because with the new JSF 2.0 partial state saving algorithm, the ammount of memory required to store views into session has been reduced to its minimal expression.

        In this article:

        http://content.jsfcentral.com/c/journal/view_article_content?cmd=view&groupId=35702&articleId=73398&version=1.8#.UkAArj9Kvb0

        At the end there is a graph showing how the state evolves for a client in a simple application. Other frameworks like Grails and Tapestry that are supposed to be "stateless" uses almost the same or more session space that MyFaces Core.

        The focus used to solve the problem until now has been to reduce the size required to store views into the state. In this context, it is questionable if the technique can be useful from performance perspective.

        In other words, it is required more information about the usefulness of the change proposed from performance perspective. I think it is better to try to solve this at spec level and live for now with a hack outside MyFaces Core code. It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown.

        Show
        Leonardo Uribe added a comment - In JSF 2.2, ViewScoped beans are stored in session, no matter if client side or server side state saving is used. The code we have right now in MyFaces Core is good enough to be extended. The problem is there is no clarity about the usefulness of the strategy proposed, because with the new JSF 2.0 partial state saving algorithm, the ammount of memory required to store views into session has been reduced to its minimal expression. In this article: http://content.jsfcentral.com/c/journal/view_article_content?cmd=view&groupId=35702&articleId=73398&version=1.8#.UkAArj9Kvb0 At the end there is a graph showing how the state evolves for a client in a simple application. Other frameworks like Grails and Tapestry that are supposed to be "stateless" uses almost the same or more session space that MyFaces Core. The focus used to solve the problem until now has been to reduce the size required to store views into the state. In this context, it is questionable if the technique can be useful from performance perspective. In other words, it is required more information about the usefulness of the change proposed from performance perspective. I think it is better to try to solve this at spec level and live for now with a hack outside MyFaces Core code. It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown.
        Hide
        Thomas Andraschko added a comment -

        Don't know if this is really usefull - The state is sooooo small if you don't blow it up with your ViewScopd beans.
        IMO The only usecass when a mixed mode is really usefull i described here: http://tandraschko.blogspot.de/2012/12/dynamical-switching-of-jsf-state-saving.html

        Show
        Thomas Andraschko added a comment - Don't know if this is really usefull - The state is sooooo small if you don't blow it up with your ViewScopd beans. IMO The only usecass when a mixed mode is really usefull i described here: http://tandraschko.blogspot.de/2012/12/dynamical-switching-of-jsf-state-saving.html

          People

          • Assignee:
            Unassigned
            Reporter:
            Ertio Lew
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development