[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534040#comment-13534040 ] Leonardo Uribe commented on MYFACES-3664: - Attached patch ( myfacesStatelessMode-6-view-pool.patch ) . In my opinion it is 90% complete, but still need more tests, and include the options about how to enable/disable the mode. > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-6-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > - In MyFaces there exists the concept of FaceletState. It is possible to use > this concept and cache even dynamic views, because each different > FaceletState can identify an specific view structure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534040#comment-13534040 ] Leonardo Uribe commented on MYFACES-3664: - Attached patch ( myfacesStatelessMode-6-view-pool.patch ) . In my opinion it is 90% complete, but still need more tests, and include the options about how to enable/disable the mode. > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-6-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > - In MyFaces there exists the concept of FaceletState. It is possible to use > this concept and cache even dynamic views, because each different > FaceletState can identify an specific view structure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534040#comment-13534040 ] Leonardo Uribe commented on MYFACES-3664: - Attached patch ( myfacesStatelessMode-6-view-pool.patch ) . In my opinion it is 90% complete, but still need more tests, and include the options about how to enable/disable the mode. > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-6-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > - In MyFaces there exists the concept of FaceletState. It is possible to use > this concept and cache even dynamic views, because each different > FaceletState can identify an specific view structure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538622#comment-13538622 ] Leonardo Uribe commented on MYFACES-3664: - Attached patch ( myfacesStatelessMode-8-view-pool.patch ) which includes the latest changes and remove the code that do the cleanup in component resource facets (head, body and form), because in MYFACES-3659 a better solution was provided. > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-6-view-pool.patch, > myfacesStatelessMode-8-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > - In MyFaces there exists the concept of FaceletState. It is possible to use > this concept and cache even dynamic views, because each different > FaceletState can identify an specific view structure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841845#comment-13841845 ] Leonardo Uribe commented on MYFACES-3664: - I have updated the patch to 2.2.x branch and I also did a full and exhaustive review of the solution. I took some time, but finally the code is ready to be committed. To enable the view pool, org.apache.myfaces.CACHE_EL_EXPRESSIONS must be set to "alwaysRecompile". It can be initialized using web config parameters or as a faces-config-extension. At the end, the view pool gives an small improvement in cpu when the page is rendered, but it reduce the amount of created objects. In ajax requests the difference is noticeable, specially in large views where the time spent building the view is more than the time spent rendering the ajax response. If no objections, I'll commit the solution proposed soon on 2.2.x branch. > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-12-view-pool.patch, > myfacesStatelessMode-6-view-pool.patch, myfacesStatelessMode-8-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > -
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842260#comment-13842260 ] Thomas Andraschko commented on MYFACES-3664: thanks for your effort Leo. Will you also do another performance/memory/troughput comparison after 2.2 release? Would be great! > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-12-view-pool.patch, > myfacesStatelessMode-6-view-pool.patch, myfacesStatelessMode-8-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > - In MyFaces there exists the concept of FaceletState. It is possible to use > this concept and cache even dynamic views, because each different > FaceletState can identify an specific view structure. -- This message was sent by Atlassian JIRA (v6.1#6144)