numberOfViewsInSessionと複数のタブの問題

Question

私のアプリケーションとメモリに大きな問題があります。アプリケーション（jsf/richfaces/faceletを持つjava）は、同時に7000人のユーザーによって使用されます。

デフォルトでは、変数com.sun.faces.numberOfViewsInSessionはweb.xmlで15に設定されています。この変数はビューのツリーを作成し、jsfは15回のクリックで特定のビューを取得します。

たとえば、アプリケーション用に3つの画面があり、Firefoxを使用しています。私は最初のタブで3番目の画面に進みます。 2番目のタブでは、最初の画面があり、次のボタンをクリックします.jsfは最初の画面を取得し、2番目の画面に移動します。

このメカニズムは素晴らしいですが、多くのメモリ（セッションで25Mo）を消費します。この数値に7000を掛け合わせると、175Goのメモリが必要です。不可能です。

私はcom.sun.faces.numberOfViewsInSessionを1（セッションごとに3Mo）に設定しようとしました。

しかし、私の例で、私は次のボタンの上に2番目のタブをクリックし、私は次のエラーを取得：

javax.servlet.ServletException: viewId:/private/pages/data/dataView.faces - View /private/pages/data/dataView.faces could not be restored. 
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:270) 
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206) 
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) 
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) 
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) 
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
at fr.generali.mezzo.front.commun.performance.filters.PerformanceFilter.doFilter(PerformanceFilter.java:72) 
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) 
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173) 
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) 
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) 
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) 
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) 
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:420) 
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) 
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) 
at java.lang.Thread.run(Thread.java:595) 

私numberOfViewsInSessionが私の、だから、1

であるため、このエラーは論理的です質問：

ビュー（2番目のタブ）にあるデータを知っているとすれば、例外をキャッチしてユーザーの新しいビューを作成するにはどうすればよいですか？

ありがとうございました。

Answer 1

あなたのアプリケーションについて持っている特定の知識を利用してビューを手動で復元することは、かすかな問題ではないかもしれません。

このパスに従うことをお望みなら、JSFでStateManager APIを利用するのではなく、例外をキャッチしてください。これにより、JSFフレームワークがビューステートをどのように管理するかをカスタマイズすることができます。

これは高度なトピックです。またはエド・バーンズ（JSFスペックリード）の言葉で：

View state management is a complex business, and few application developers will have to worry about customizing it.

すでにJSF 2.0を使用していない場合は、言った、私は非常にこれにアップグレードすることをお勧めします。 JSF 2.0の大きな新機能は、パーシャルステートセーブです。これにより、状態を格納するために必要なメモリ量が大幅に削減されます。

さらに別のオプションは、com.sun.faces.numberOfViewsInSessionがクライアントの状態を使用しているようなパラメータについての知識をすでに持っていると考えていたかもしれません。これは隠しフィールドにビューステートを格納し、クライアントが分散メモリとして使用されるため基本的に無制限のメモリを与えます。もちろん、これは高価なネットワークオーバーヘッドになります。 AJAXの場合、このオーバーヘッドは非常に大きく、考慮することは不可能です。