遇到JSF填补我们会话的问题.前几天我们遇到了系统崩溃.发送堆给IBM进行审核,发现我们有一些大到50M的会话.他们在会话中发现了JSF组件,而且有些非常大.
那么,有没有可以完成的调整?配置项看看?或其他方向.
我们的系统是使用JSF和Spring为表示层构建的,后端是EJB,Spring和Hibernate都在WebSphere 6.1上运行.
JSF是一项非常有用的技术,但您肯定可以自己使用它.
听起来,要么你要膨胀视图状态的大小(通过在组件上设置大值),要么你将对组件的引用泄漏到其他会话状态(这会很糟糕).另一个潜在的罪魁祸首是一个过大的视图(我已经看到人们可以轻松构建UI树,从而导致数据表随处可见的非常大的控制图).我知道IBM提供了丰富的文本和电子表格控件 - 我无法评论这些控件对状态大小的影响.
悬而未决的成果是检查faces-config.xml中为会话范围配置的托管bean .
JSF在请求之间保存两件事:
视图(页面上的所有控件)
视图状态(控件的状态)
这些是分开的,因为某些控件(例如数据表的子项)可以具有多个状态(每行一个).状态可以保存到表单上的隐藏字段(如果未加密,可能是一个很大的安全隐患)或会话中.为了容纳共享相同会话的多个浏览器窗口(并且在一些实现中,支持后退按钮),存储多个视图.
应该有一个配置选项来设置应用程序在任何给定时间在给定用户的会话中保留的视图状态数.
您可以通过提供一个测量保存的视图/状态大小的StateManager来测量视图状态的大小(使用带有StateManager的公共构造函数在faces-config.xml中配置StateManager - 有关详细信息,请参阅JSF规范 PDF;状态是可序列化的,您可以通过将其转储到流来检查其大小.
大多数IDE构建的JSF应用程序都有支持bean.通过会话bean作用域可以保持比你想要的更长的状态,这会对会话造成压力.由于每页往往有一个支持bean,所以页面越多,问题就越大.检查faces-config.xml以查看这是否是潜在的问题根源.
您可以做的其他事情是在web.xml中配置HttpSessionAttributeListener.您可以获得堆栈跟踪以帮助识别应用中的问题区域.