2011-01-30 3 views
2

Приветствия,Использование памяти для использования uicomponent tree

У меня есть приложение с богатыми лицами (3.3.2.SR1). Приложение использует ModelPanel для просмотра объектов. Все модальные панели не отображаются, пока я не хочу их показать (rendered = false). Приложение становится большим и использует много отношений от одной панели к другим. Все работает отлично, но похоже, что richfaces создает дерево UIComponent в памяти для всех возможных случаев, если компонент rendred равен true или false. Когда я попытался проверить использование памяти в приложении (я использовал YourKit Java Profiler для этих нужд), я вижу, что он использует много памяти для одного сеанса.

Я использую Facelets вместе с RichFaces и я пытался использовать

<c:if test="rendred condition"... /> content </c:if> 

Он начинает использовать значительно меньше памяти, но ... когда я засавить область с панели управления на родительском экране будут остановлены работать. Я подозреваю, что это связано с тем, что каждый раз, когда дерево компонентов изменяется, оно воссоздает все дерево, а у меня есть детали несинхронизированного клиента (html) и сервера (лица).

Может ли кто-нибудь предложить мне способ сокращения использования памяти? У меня есть настоящая проблема с ним, поскольку объект StandardSession в HeapMemory использует 60-150Mb. И почти вся эта память используется для UIControls.

Пример задачи:

У меня есть страница, которая имеет ссылки на ПАНЕЛЬ1, panel2, панелью3.

Группа является:

<rich:modalPanel > 
    <a4j:outputPanel layout="block" 
      rendered="#{PanelBeanHolder.renderedViewScreen}"> 
     <ui:insert name="panelContent" /> 
    </a4j:outputPanel> 
</rich:modalPanel> 

Я рендеринг только панели, когда действие для этого выполняется. И не хотите загружать элементы управления пользовательского интерфейса для панели вывода, пока она мне не понадобится.

Заранее спасибо.

P.S. Я пытался сделать следующее, чтобы улучшить ситуацию

Настройка количество просмотров в сессии в web.xml с:

<context-param> 
    <param-name>com.sun.faces.numberOfViewsInSession</param-name> 
    <param-value>4</param-value> 
</context-param> 

<context-param> 
    <param-name>com.sun.faces.numberOfLogicalViews</param-name> 
    <param-value>4</param-value> 
</context-param> 

Он должен улучшить объект StateHolder, но это не помогает много , Я делал измерения и использование памяти растет, когда эти числа растут. Но, когда я устал устанавливать их на 1,1, некоторые страницы перестали работать. Иногда запрос отправляется на страницу приветствия. 2,2 улучшила ситуацию, но проблема с пересылкой на приветственные страницы все еще случается.

Прочитано до использовать клиентский режим в javax.faces.STATE_SAVING_METHOD. Он по-прежнему использует большую память для модели UIComponent. Даже если объекты сериализованы и должны быть сохранены в форме.

Пытался переписывания stateManager в faces.config:

<state-manager>org.ajax4jsf.application.CompressAjaxStateManager</state-manager> 

и переписать buildViewState и restoreView для сжатия потока. Это не очень помогает.

ответ

3

JSF использует дерево компонентов с состоянием, которое поддерживается между запросами. По умолчанию это обычно сохраняется в сеансе.Есть функции, которые вы можете использовать для управления этим.

Настройка параметров состояния экономии

Есть параметры, как правило, специфичные для реализации, чтобы контролировать количество просмотров хранящимся в сессии - в зависимости от того, как ведет себя приложение, это может быть легкая победа.

Вы можете сохранить состояние в формах, используя параметр javax.faces.STATE_SAVING_METHOD. Однако имейте в виду, что вы отправляете больше информации для каждого запроса, и есть риски безопасности, позволяющие клиенту диктовать состояние на стороне сервера (убедитесь, что вы довольны тем, как ваша реализация шифрует эти данные). Вам нужно будет проверить совместимость с вашими библиотеками компонентов (например, RichFaces), особенно если вы используете AJAX.

В JSF 2 используется новый механизм экономии состояний, который уменьшает накладные расходы сеанса; ваш faces-config.xml необходимо будет обновить до версии 2.0. Я считаю, что эта идея исходила из Apache Trinidad, поэтому вы можете извлечь из нее предварительную версию JSF 2.

Сделайте свое собственное состояние сохранения и/или создание вида

Внедрение ваших собственных StateManager и/или ViewHandler позволяет принимать программный контроль над тем, как вид обрабатываются. Например, вы можете написать StateManager, который сохранял представления в базе данных (с соответствующим тайм-аутом и очисткой).

Использование компонента связывания и переходные элементы управления

Вы можете взять программный контроль над, как создаются компоненты. Из спецификации на связывание:

  • Когда экземпляр компонента сначала создается (обычно в силу того, ссылается UIComponentELTag на странице JSP), реализация JSF будет получать ValueExpression для связывания имя и позвоните по телефону getValue(). Если этот вызов возвращает ненулевое значение UIComponent (поскольку JavaBean программно инстанцировал и настроил компонент уже), этот экземпляр будет добавлен в созданное дерево компонентов. Если вызов возвращает null, будет создан новый экземпляр компонента, добавленный в дерево компонентов, и setValue() будет вызываться на ValueExpression (что приведет к тому, что свойство на JavaBean будет установлено на вновь созданный экземпляр компонента).
  • Когда дерево компонентов воссоздается во время фазы восстановления для цикла жизненного цикла запроса, для каждого компонента, который имеет ValueExpression, связанный с именем «привязка», на него будет вызываться setValue(), передавая экземпляр воссозданного компонента.

Вы могли бы использовать это с transient собственности на детей, чтобы управлять программно контролировать создание/уничтожение дочерних компонентов. Это ручное и немного грязное, но может работать в крайних случаях.

Я уверен, что это не исчерпывающий список.

+1

+1 Это хорошее объяснение. Особенно JSF 2 кажется довольно огромной победой с частичной функцией сохранения состояния.JSF 2 также значительно упростил API для обработки состояния при написании собственного компонента (это, конечно, не помогает TS). Я также хочу добавить, что реализация вашего собственного StateManager на самом деле является передовой темой, и, возможно, это не делается беззаботно, если вы не чувствуете себя очень комфортно с JSF API. –

+0

Благодарим вас за ответ. Я добавил дополнительную информацию на свой пост, который должен описать более подробную информацию, основанную на моем исследовании. – Dmitry

Смежные вопросы