ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

I was reading the section in the documentation that talks about using custom attributes, and wasn't exactly sure what that means? So this example is referenced in here:

<context-param>
<param-name>com.icesoft.faces.portlet.hiddenAttributes</param-name>
<param-value>THEME_DISPLAY</param-value>
</context-param>

What about the theme_display needs to be kept up to date? I take it, it posts some parameters with the request to the portal?

Out of curiousity, what triggers icefaces to know that a Renderable bean has gone out of scope?

I've been reading through the icefaces documentation to try to really get up to speed on 1.7. The documentation definitely helps a bit to clarify some of the new stuff. I was wondering though if using the portlet tag should noticable speed up client side rendering?

Basically, I've went through and optimized a lot of our portlets thinking that would help the awful looking performance of full page refreshes (I know they won't necessarily happen all that often, but they still take forever, like in the magnitude of up to 10 seconds or more, when there are a lot of portlets on the page.) So basically I eliminated some of the unnecessary render calls we had and some other processing. While the server optimizations did help in general, the pages still can be a bit brutal to render on the client side. I did notice that one of our machines on the network, not even a particularly fast one, can render pages through firefox EXTREMELY fast, like amazingly fast compared to my dual core machine I develop on. On my dev machine, firefox struggles to load the same pages as the slower machine (my dev machine also has 4 gig of memory, the other probably has 2 gig). IE loads much faster when used on my dev machine than firefox also.

Basically, should I notice a performance increase if I use the portlet tag on my pages? Are there any other things I could configure in my app or portlets that might help firefox with rendering? Or are there browser settings that in particular work better? I'm a little unsure why firefox performance is so drastically different between machines.

Are there any general client side performance tips at all?

I've been noticing that in 1.7RC1, when a serverside error happens.. some strange things will occur. One of them I know of offhand, is that tomcat sends an error page to icefaces of the push mechanism and then my portal page blanks out. The top 25% is completely white and the bottom 75% is completely black.

Is this what is supposed to happen?

Firebug shows this when the error occurs:

POST http://localhost:8084/portalappweb/block/send-receive-updates500 (1125ms)

<html><head><title>Apache Tomcat/6.0.16 - Error report</title><style><!--H1 {font-family:Tahoma,Arial
....

this also then includes the stacktrace... it seems like it's more severe errors that cause this.. in this case, a property on one of my beans is said to be missing, for whatever reason.

I meant act as if they are in the same WAR in regards to rendering mostly, so if some backend state changed, and I call a specific on-demand renderer, can that render cause Renderables in the two different WARS to push content?

I guess I'm a little unsure of what supporting "multiple wars" means in the case of icefaces. I like bundling my portlets into different wars to kind of categorize them.. so you could simply not deploy a war if you didn't have a need for a set or portlets... I also then bundle common application scoped beans into a separate jar library to include in both.. but I guess I'm not sure if that will let them work together or not? I'm sure your documentation will straighten me out on this when I get a chance to look at it, which is hopefully soon.

We are still using a single war when we received this.

I meant that we exercised all the functionality it has available currently in our application which results in quite a lot of renders happening at the same time (maybe 15 or so). I didn't mean this in a multiuser scenario, just as much as we can push with a single user, to show off as much capabilities as possible. The statement wasn't meant as much more than maxing out the capabilities that can be done by a single user.

I agree, freezing like this tends to happen when an OOME occurs. I'm surprised the server even responded again. I didn't have the console available, so I didn't know that's what happened.

Our Pergem space is at 256MB currently since we load a lot of classes due to the amount of things we integrate and include.

We also hadn't deployed and undeployed either when tomcat started it. It really could just in general be a result of icefaces requirements having gone up. It's mostly a curiousity since I didn't think we were that close to exhausting our perm gen space that the 1.6.2 to 1.7 mem usage would throw it over the edge.

I just wanted to bring it to your attention in case it was in any way helpful.

Great, glad to know documentation has been written for it, I'll go and read about it. Thanks!

Before I venture into creating a new WAR file containing icefaces portlets, which needs to be part of the same portal application as a current WAR file of portlets that we have, is this functionality deemed working in 1.7RC1? If so, I'll proceed to implement this for our application, but I just want to make sure there hasn't been any changes in 1.7 in regards to that feature. I do remember running into trouble with portlets in the same war in DR3 in regards to that feature being in development. Are there any known gotchas with implementing this? Or should the portlets in the 2 wars work together more or less as if they were in the same WAR?

Thanks!

I had previously used DR1 and DR2 of 1.7 without any major problems (other than visual glitches) in our project. We switched back to 1.6.2 temporarily because the DR3 release incorporated the multiple WAR file features which made that release fairly unusable with liferay. Since 1.7 RC1 came back out, we decided to give it a try since we figure it should now be in a stable enough state (and had no major problems with DR1 and DR2). Well it all seemed to be working fine until we were doing a small demo for some other developers and pushed our application to it's limits (which worked fine in 1.6.2). Shortly after we performed an operation which causes a lot of server pushed updates, everything came to a grinding halt and hung for several minutes. When it finally unfroze, the UI was very unresponsive and I saw the below expection in our log. Unfortunately, due to the nature of how it happened, I can't give you any more information than this stack trace, but I was wondering if there was anything known, or if maybe some additional load testing might need to be done? I'll be investigating this more on our side to verify that it's definitely a 1.7RC1 issue, but I thought I should bring it up now since I'm 99% sure that it's an RC1 issue (our app didn't have any changes when we switched to 1.7 and therefore should have still been working fine in 1.6.2). This is in Liferay portal 4.4.2 BTW.

Exception in thread "Render Thread - 1" java.lang.OutOfMemoryError: PermGen space
at sun.misc.Unsafe.defineClass(Native Method)
at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
at java.security.AccessController.doPrivileged(Native Method)
at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:5
9)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:28)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java
:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:1381
)
at com.icesoft.faces.context.effects.CurrentStyle.apply(CurrentStyle.java:152)
at com.icesoft.faces.renderkit.dom_html_basic.PassThruAttributeRenderer.renderAttrib
utes(PassThruAttributeRenderer.java:168)
at com.icesoft.faces.renderkit.dom_html_basic.PassThruAttributeRenderer.renderAttrib
utes(PassThruAttributeRenderer.java:143)
at com.icesoft.faces.renderkit.dom_html_basic.CommandLinkRenderer.encodeBegin(Comman
dLinkRenderer.java:137)
at com.icesoft.faces.component.ext.renderkit.CommandLinkRenderer.encodeBegin(Command
LinkRenderer.java:54)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:703)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildr
en(DomBasicRenderer.java:350)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRend
erer.java:92)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:721)
at com.icesoft.faces.component.util.CustomComponentUtils.renderChild(CustomComponent
Utils.java:339)
at com.icesoft.faces.component.tree.TreeNodeRenderer.encodeEnd(TreeNodeRenderer.java
:73)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:740)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildr
en(DomBasicRenderer.java:362)
at com.icesoft.faces.component.tree.TreeRenderer.encodeNode(TreeRenderer.java:585)
at com.icesoft.faces.component.tree.TreeRenderer.encodeParentAndChildNodes(TreeRende
rer.java:291)
at com.icesoft.faces.component.tree.TreeRenderer.encodeParentAndChildNodes(TreeRende
rer.java:342)
at com.icesoft.faces.component.tree.TreeRenderer.encodeChildren(TreeRenderer.java:24
4)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:721)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildr
en(DomBasicRenderer.java:352)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRend
erer.java:92)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:721)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildr
en(DomBasicRenderer.java:352)

I periodically see this problem in the tomcat 6.0.14 tomcat-liferay bundle. There doesn't appear to be any obvious cause for it, since it seems to handle randomly. Sometimes when I click a button, such as to bring up a popup panel, it will just sit there and spin. If I reclick the button, it will instantly work fine. I also can't say that I see this happen frequently but it does happen on 1.7RC1 and doesn't appear to happen at all on 1.6.2.

Ok, I'll see if I can get a small example of something like this together that illustrates the problem. I have a feeling that the way we are doing it is most likely the problem. We are using Renderers in a common application scoped bean that is injected into a request scoped bean so it can register and deregister itself throughout it's lifecycle. Somehow, it's not being destroyed and is somehow related to the mechanism we've created.

Great! Though, I meant to respond and ask if this problem affects 1.6.2? We switched back to it until 1.7 became more stable. I could have swore this all worked before in 1.6, which is why I want to make sure whether or not I'm making an error or if this same issue is known for 1.6.2 as well.

I'm having trouble with a single liferay portlet that isn't rendering through the server initiated rendering. When I debug it, I see the request bean itself being accessed in order to get the properties to refresh on the portlet but nothing shows up. It's the only portlet I'm having trouble with. I also noticed that my getProperty is being called a ton of times (it's a collection property holding only 1 element, I wouldn't think it would need to be called so many time). This is causing me to wonder if my beans are being disposed of properly. I tried to turn on debugging for icefaces and I'm not seeing the renderingException() method called for any of my beans, nor am I really seeing anything about the views. What are the log4j settings I need to turn this on (I think I can do it with log4j, right?) At this point, I'm having some doubts my application is working correctly anymore and want to figure out the easiest way to verify whether or not beans are being created and disposed of correctly (currently, when the beans are created, they add themselves to different OnDemandRenderers that are kept in an application scoped bean, when the renderException occurs, then they are supposed to remove themselves from the appropriate listener, is there anything wrong with this approach?). I really thought everything was working correctly, but not I'm just not sure.

Oh, I see. That's disappointing. I'll just stay on DR2 for now then.

I had moved all my portlets to a single war file several months ago so that I didn't have to deal with this limitation. All of my portlets are in the same WAR. Is there anything else that could cause this issue? I don't see this issue if I substitute the DR3 jars with DR2 jars.