Migration to icefaces 3.3.0 and liferay 6.2 - application freezing effects

[Andreas Dörfler, geändert vor 9 Jahren.]

Hi there,

we are migrating our application to icefaces 3.3.0 with Mojarra JSF 2.1.21.
Unfortunately we observe that our IceFaces-components are undergoing a freezing effect:
you cannot click buttons, tabs etc. the components no longer respond.
Only after a server restart the components work again and after a while (espcially after a deployment) we observe again the mentioned freezing effect.

Regarding the Configuration of our IceFaces-Portlets we followed all the steps which are described in:
https://dev.liferay.com/discover/deployment/-/knowledge_base/6-2/installing-liferay-on-oracle-weblogic-12c-12-1-2-and-h#configuration-for-deploying-jsf-portlets

We also installed the Liferay IceFaces Demo-Portlet, which works, but also shows the freezing effect, if one of our portlets is freezing. But we could not find any differences in the configuration.

We are working with the following environment
Liferay Portal 6.2 SP9
WebLogic 12c (weblogic-12.1.2.0)
Mojarra 2.1.21
ICEfaces 3.3

These are our Ivy-dependencies:
<dependency org="icefaces" name="icefaces" rev="3.3.0">
<artifact name="commons-beanutils" type="jar" />
<artifact name="commons-digester" type="jar" />
<artifact name="FastInfoset" type="jar" />
<artifact name="backport-util-concurrent" type="jar" />
<artifact name="icefaces" type="jar" />
<artifact name="icefaces-ace" type="jar"/>
<artifact name="icefaces-compat" type="jar" />
<artifact name="krysalis-jCharts-1.0.0-alpha-1" type="jar"/>
<artifact name="jxl-2.6.12" type="jar" />
<!-- <artifact name="icepush" type="jar" />-->
</dependency>
<dependency org="liferay-faces-bridge" name="liferay-faces-bridge" rev="3.2.4">
<artifact name="liferay-faces-portal-3.2.4-ga5" type="jar" />
<artifact name="liferay-faces-bridge-api-3.2.4-ga5" type="jar" />
<artifact name="liferay-faces-bridge-impl-3.2.4-ga5" type="jar" />
<artifact name="liferay-faces-util-3.2.4-ga5" type="jar" />
<artifact name="liferay-faces-alloy-3.2.4-ga5" type="jar" />
</dependency>

We do not ship the JSF-Jars in our WARs. If I use the Weblogic Classloader Analysis Tool I find only one JSF-Jar in the ClassPath ( Mojarra 2.1.21).

Besides the warning (Multiple JSF Applications found on same ClassLoader ...) we also do not understand, why we get following errors:
<Error> <javax.faces> <BEA-000000> <Application was not properly initialized at startup, could not find Factory: javax.faces.lifecycle.LifecycleFactory.
Attempting to find backup.><Error> <javax.faces> <BEA-000000>
<Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory.
Attempting to find backup.><Error> <javax.faces> <BEA-000000>
<Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory.
Attempting to find backup.>

Last but not least we observe the following warnings/exceptions in our log files:
Nov 05, 2014 4:20:16 PM org.icefaces.impl.event.BridgeSetup getBodyResourcesWarning: Unable to find WindowScope for view /info.xhtml<Error>
<javax.enterprise.resource.webcontainer.jsf.application> <serv.group.com>
<SERVER_1> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1415172956098>
<BEA-000000> <Error Rendering View[/suche.xhtml] java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1234)
at java.util.regex.Matcher.reset(Matcher.java:308)
at java.util.regex.Matcher.<init>(Matcher.java:228)
at java.util.regex.Pattern.matcher(Pattern.java:1088)
at org.icefaces.impl.util.DOMUtils.printNode(DOMUtils.java:376)
at org.icefaces.impl.util.DOMUtils.printNode(DOMUtils.java:355)
at org.icefaces.impl.util.DOMUtils.printNode(DOMUtils.java:355)
at org.icefaces.impl.util.DOMUtils.printNode(DOMUtils.java:355)
at org.icefaces.impl.util.DOMUtils.printNodeCDATA(DOMUtils.java:286)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:241)
at com.liferay.faces.util.context.PartialViewContextCleanupImpl.processPartial(PartialViewContextCleanupImpl.java:91)
at javax.faces.context.PartialViewContextWrapper.processPartial(PartialViewContextWrapper.java:183)
at com.liferay.faces.util.context.PartialViewContextOnChangeImpl.processPartial(PartialViewContextOnChangeImpl.java:105)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:973)

Does anybody else experienced those freezing effects?

andreas

[Vernon Singleton, geändert vor 9 Jahren.]

Hi Andreas,

Thanks for reporting these issues here.

Andreas Dörfler:

ICEfaces 3.3

Cool. Are you an an ICEfaces EE customer?

I will be taking a look at this ...

- Vernon

[Andreas Dörfler, geändert vor 9 Jahren.]

Hi Vernon,

no, we are not ICEfaces EE customer

bye

andreas

[Vernon Singleton, geändert vor 9 Jahren.]

Hi Andreas,

We found a bug that is probably causing one of your issues.

I opened this ticket to address it:
https://issues.liferay.com/browse/FACES-2097

I have attached a snapshot icefaces3-portlet war built with the fixed weblogic profile.
Please try this portlet in your environment, and see if it freezes.

This brings me to a second point.
These artifacts are not in the war:
<artifact name="commons-digester" type="jar" />
<artifact name="backport-util-concurrent" type="jar" />
<artifact name="krysalis-jCharts-1.0.0-alpha-1" type="jar"/>
<artifact name="jxl-2.6.12" type="jar" />

Please remove these artifacts from your other portlets for our testing, and let's see if we still get the freezing.

I am currently testing the attached snapshot icefaces3-portlet deployed on Liferay Portal 6.2 SP9 running on WebLogic 12c (weblogic-12.1.2.0), and I am not seeing any freezing until the warning message in the red banner appears at the top of the portal due to session timeout.

Are you getting the warning in the red banner when this freezing happens?

- Vernon

[Andreas Dörfler, geändert vor 9 Jahren.]

Hi Vernon,

first of all thanks a lot for your efforts.
We fixed the icefaces-dependencies in our ivy.xml according to your instructions, then we have installed the patch and tested (as so often) with increasing enthusiasm.
But after a while we came back to the mysterious freezing effect, we also still read the above reported exceptions in our log files.
We get the freezing effect long before the liferay portal session time out.

When the freezing effects occurs, we observe with the Firebug under Debug-Info the following output:
[window] full submit to https://portal-test-1.MyFirma.de:18150/group/vip/administration?p_p_id=VIPAdmin_WAR_AuskunftsPortletApp&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-4&p_p_col_count=1&_VIPAdmin_WAR_AuskunftsPortletApp__jsfBridgeAjax=true&_VIPAdmin_WAR_AuskunftsPortletApp__facesViewIdResource=%2Fvipadministration.xhtml
javax.faces.execute: @all
javax.faces.render: @all
javax.faces.source: _VIPAdmin_WAR_AuskunftsPortletApp_:j_idt5:vipadmin-panel:0.2
view ID: null
event type: click

[window] full submit to https://portal-test.MyFirma.de:18150/group/vip/suche?p_p_id=InfoPortlet_WAR_AuskunftsPortletApp&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-4&p_p_col_count=2&_InfoPortlet_WAR_AuskunftsPortletApp__jsfBridgeAjax=true&_InfoPortlet_WAR_AuskunftsPortletApp__facesViewIdResource=%2Finfo.xhtml
javax.faces.execute: @all
javax.faces.render: @all
javax.faces.source: _InfoPortlet_WAR_AuskunftsPortletApp_:j_idt4:j_idt11
view ID: nullevent type: click

Without freezing effect the output of DebugInfo looks like that (the view ID is not null!)
[window] full submit to https://portal-test-1.MyFirma.de:18150/group/vip/start?p_p_id=SuchenPortlet_WAR_AuskunftsPortletApp&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-4&p_p_col_count=3&p_p_col_pos=1&_SuchenPortlet_WAR_AuskunftsPortletApp__jsfBridgeAjax=true&_SuchenPortlet_WAR_AuskunftsPortletApp__facesViewIdResource=%2Fsuche.xhtml
javax.faces.execute: @all
javax.faces.render: @all
javax.faces.source: _SuchenPortlet_WAR_AuskunftsPortletApp_:j_idt6:suche-panel:0.0
view ID: v2k2n2za
event type: click

start?...ce.core (Zeile 1)
[window] persisted focus for element "_SuchenPortlet_WAR_AuskunftsPortletApp_:j_idt6:suche-panel:0.0"
2
start?...ce.core (Zeile 1)

[window] applied updates >>
update["_SuchenPortlet_WAR_AuskunftsPortletApp_:j_idt6:suche-panel:0ht0"]: <td class="icePnlTb" id="_SuchenPortlet_....
update["_SuchenPortlet_WAR_AuskunftsPortletApp_:j_idt6:suche-panel:0ht1"]: <td class="icePnlTb" id="_SuchenPortlet_....
update["_SuchenPortlet_WAR_AuskunftsPortletApp_:j_idt6:suche-panel:0td4"]: <td class="icePnlTbSetCnt" id="_SuchenPo....
update["javax.faces.ViewState"]: 2189726870726954302:2850681365565659344....
eval: document.getElementById('_SuchenPortlet_....
eval: var iceFormIdList=['_SuchenPortlet_WAR_A....
extension

Let us know, if you need more information or any configuration-files of our application

Regards

andreas

[Vernon Singleton, geändert vor 9 Jahren.]

Hi Andreas,

Andreas Dörfler:

But after a while we came back to the mysterious freezing effect, we also still read the above reported exceptions in our log files.
We get the freezing effect long before the liferay portal session time out.

How long does it usually take before the freezing starts to occur?
Does a page refresh clear up the freezing?
Would this freezing occur on a portlet that does not require authentication?

[Andreas Dörfler, geändert vor 9 Jahren.]

Hi Vernon,

Vernon Singleton:

How long does it usually take before the freezing starts to occur?

Mostly we can generate the freezing effect by a deployment of anyone of our portlets.
Sometimes, however, the freezing effect also occurs out of the blue, which makes the error production-critical.

Vernon Singleton:

Does a page refresh clear up the freezing?

No, once a page is frozen, it continues to be frozen, only a server start clears up the freezing effect.

Vernon Singleton:

Would this freezing occur on a portlet that does not require authentication?

Our portlets are located on private pages which belongs to a certain community/site. We do not use any further liferay specfic roles or authentication mechanisms.
Up to now we had not tested our portlets on public pages.

We have the suspicion that in our environment the JSF-factory is loaded (after a deployment) more than one time leading to a confusing situation, which ends up with frozen pages.

Regards

andreas

[Vernon Singleton, geändert vor 9 Jahren.]

Andreas Dörfler:

Mostly we can generate the freezing effect by a deployment of anyone of our portlets.

Does the freezing occur with only our icefaces3-portlet on its own page?
I'm referring to the icefaces3-portlet that I attached above.

[Andreas Dörfler, geändert vor 8 Jahren.]

Hi there,

after we have delivered our release with Liferay 6.1.2 and IceFaces 1.8, we come back to our freezing problem, which we observe when we work with Liferay 6.2 (SP 11) and IceFaces 3.3.
We have written a Test-Portlet (ADPortlet2Test, s. attachment) with no functionality but with the configuration which we use for our portlets (web.xml, portlet.xml, weblogic.xml etc.)

We have a WLS 12c-Server running Liferay 6.2 (SP11) an we have deployed the icefaces3-portlet which provided us Vernon Singleton (see above).
It doesn't matter if you are testing on a Admin-Server or in an environment with Admin- and Managed Server.
If we deploy "behind the scenes" our ADPortlet2Test and continue to work with the Job-Application-Portlet, we observe the freezing effect (which somestimes disappear after refreshing the page).

In the logs we find the error messages which we typically find, when we test the portlets of our portal application:

<04.05.2015 18:08 Uhr MESZ> <Error> <javax.faces> <BEA-000000> <Die Anwendung wurde bei Systemstart nicht einwandfrei in
itialisiert, Factory konnte nicht gefunden werden: javax.faces.context.FacesContextFactory. R++griff versucht.>
...
<04.05.2015 17:30 Uhr MESZ> <Error> <javax.enterprise.resource.webcontainer.jsf.application> <BEA-00
0000> <Error Rendering View[/views/portletViewMode.xhtml]
java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1234)
at java.util.regex.Matcher.reset(Matcher.java:308)
at java.util.regex.Matcher.<init>(Matcher.java:228)
at java.util.regex.Pattern.matcher(Pattern.java:1088)
at org.icefaces.impl.util.DOMUtils.printNode(DOMUtils.java:376)
Truncated. see log file for complete stacktrace
...
Mai 05, 2015 4:42:44 PM org.icefaces.impl.event.BridgeSetup getBodyResources
Warnung: Unable to find WindowScope for view /views/portletViewMode.xhtml

Last but not least we find always the following warning in our logs:
<04.05.2015 18:11 Uhr MESZ> <Warning> <javax.faces> <BEA-000000> <Multiple JSF Applications found on same ClassLoader.
Unable to safely determine which FactoryManager instance to use. Defaulting to first match.>

Regards

andreas

[Andreas Dörfler, geändert vor 8 Jahren.]

Hi there,

while investigating the freezing effect we have discovered an interesting issue:
If we deploy our test portlet with the liferay deployment method (via the liferay autodeploy folder) we cannot reproduce the error. Even if we deliver our test portlet with faces-config.xml and the liferay faces bridge we do not get any errors regardless how often we deploy our test portlet (see attached vip.ADPortletApp2Test+JSF-4Liferay.war).

If we use the standard weblogic deployment (via admin console or script) we can reproduce the error and we get the well known JSF warnings (<Multiple JSF Applications found on same ClassLoader. ...) and errors although our test portlet doesn't contain anything that is related with JSF (no faces-config.xml, no liferay faces bridge, see attached vip.ADPortletApp2Test-NoJSF-4WLS.war).

We have the impression that the weblogic deployment leads to a classloader pollution which is subsequently responsible for the error. The point is, however, you cannot use the liferay in a weblogic cluster.

As far as we know the liferay deployment generates the liferay-web.xml and adds stuff to web.xml.
We wonder what else could be the difference between liferay deployment and weblogic deployment.

andreas

[Juan Gonzalez, geändert vor 8 Jahren.]

Hi Andreas,

in order to deploy properly in a webapp console,, Liferay should preprocess your portlet WAR.

If your server config. doesn't support hotdeploy, then you should do this preprocessing using some Liferay SDK or Maven tasks for that purpose, "ant direct-deploy" for example. For doing this you would need to configure a local weblogic server and the SDK properties pointing to it, so the WAR is created according to your server type.

Please read this for more info:

https://www.liferay.com/documentation/liferay-portal/6.2/development/-/ai/deploying-your-plugins-hot-deploy-vs-auto-deploy

[Andreas Dörfler, geändert vor 8 Jahren.]

Hi Juan,

thank you for your hints concerning the build- and deployment process. However, our hope that the revised deployment process leads to a disappearance of the freezing effect has not been fulfilled.
We can systematically reproduce the error even with our Liferay compatible portlets.
When the freezing effect occurs, we detect the following entries in the HTML code of the page in question:

<form action= [...]
_1_WAR_icefaces3portlet_INSTANCE_zkMEZEvkx64u__facesViewIdRender=%2Fviews%2FportletViewMode.xhtml"
id="null-retrieve-update" method="post"
name="null-retrieve-update">
<input name="null-retrieve-update" type="hidden" value="null-retrieve-update" />
<input name="javax.faces.encodedURL" type="hidden" value="https://portal-testtestm1.wwk.de:22500/group/test/testpage?p_p_id=1_WAR_icefaces3portlet_INSTANCE_zkMEZEvkx64u&amp;p_p_lifecycle=2&amp;p_p_state=normal&amp;p_p_mode=view&amp;p_p_cacheability=cacheLevelPage&amp;p_p_col_id=column-4&amp;p_p_col_count=3&amp;p_p_col_pos=2&amp;_1_WAR_icefaces3portlet_INSTANCE_zkMEZEvkx64u__jsfBridgeAjax=true&amp;
[...]
_1_WAR_icefaces3portlet_INSTANCE_zkMEZEvkx64u__facesViewIdResource=%2Fviews%2FportletViewMode.xhtml" />
<script id="null-retrieve-update:null-retrieve-update_captureSubmit"
type="text/javascript">ice.captureSubmit("null-retrieve-update",false);
ice.captureKeypress("null-retrieve-update",null);
</script>
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-537845451432285322:8443481535732176537" autocomplete="off"></input>

For some reason Liferay(?)/the Faces Bridge(?) or IceFaces(?) isn't able to use the correct values for the ids/names, e.g. name="null-retrieve-update".
We suppose that this behaviour causes the freezing effect.

Thanks and regards

andreas

[Vernon Singleton, geändert vor 8 Jahren.]

Hi Andreas,

From your symptoms, it looks like the the “ice.view” request PARAMETER probably isn’t getting submitted correctly. Given that information ...

We came across this issue on the ice-faces jira page:
http://jira.icesoft.org/browse/ICE-10050

This issue definitely looks relevant to the symptoms you are seeing. This issue has been fixed in their EE-3.3.0.GA_P02. So it looks like you would need to be an EE customer of theirs in order to get this fix.

- Vernon