voyent
Using Icefaces Push for IPC between separate war files  XML
Forum Index -> Async HTTP Server
Author Message
mark.streeter

Joined: 15/Oct/2007 00:00:00
Messages: 9
Offline


I am using Icefaces 1.7.1, activeMQ 5.0.0 and liferay-portal-tomcat-5.5-5.0.1. I have the asynchronous HTTP server working in a stand alone tomcat 5.5.25 server. I tested this with the file upload component.

I also have gotten Icefaces push IPC working within the same war file. My question is it possible to use the AHS to get OnDemandRenderering to work for IPC between war files? I have everything set up and the AHS is running as a portlet under liferay and connects to activeMQ successfully.

The problem is that I have the render manager declared in two separate faces.config files. When I call renderManager.getOnDemandRenderer(IPC_GROUP), I get two different instances of the OnDemandRenderer between war applications. Is there a centralized context I should be using located in the AHS or Liferay?

Update: I have now verified that AHS works properly in Liferay, by using a file upload component successfully. I killed the activemq server to verify that asynchronous pushes were actually being relayed through JMS.
patrick.corless

Joined: 26/Oct/2004 00:00:00
Messages: 1982
Offline


On the RenderManager in 1.7.1 there is a flag for broadcasted. This will enable the JMS enabled renderManger. Unfortunately there isn't much in the way of documentation. However with a good IDE you should be able to figure it out.
[Email]
mark.streeter

Joined: 15/Oct/2007 00:00:00
Messages: 9
Offline


Thanks for the reply. I tried setting the broadcasted flag to true and it didn't seem to have an effect. Maybe there is a trick I was missing. I also tried the SessionRenderer which uses static methods with no luck.

In the end I decided to just package everything into the same war, as is advised in the Liferay documentation, "if you have dependencies between wars you are probably not structuring your project correctly." The programs did use a lot of common classes and putting them in the same war eliminated a lot of context and jar loading redundency. No more perm gen memory errors. I bet the memory crusher was the Hibernate session manager and it's cache running in three different web apps.
deryk.sinotte


Joined: 26/Oct/2004 00:00:00
Messages: 1008
Offline


The broadcast code was just recently ported form the old Enterprise version of ICEfaces which no longer exists. It hasn't been as ruggedly tested as we'd like (think of it as an early access API) so that's why it's not as fully documented yet.

There is a blurb in the release notes for 1.7.1 regarding "New Broadcast Render capabilities". The broadcast flag on the RenderManager or SessionRenderer is one part but there is also a context param that looks like it needs to be set to true:

Code:
com.icesoft.faces.async.render.broadcasted


From the documentation and the source code I infer that this needs to be true no matter what you do programmatically.

The other thing you probably need to do that doesn't appear to be documented is to create a separate JMS topic for broadcast rendering. It follows the same steps as creating topics for AHS but has a different topic name. The AHS topics are:

Code:
    public static final String CONTEXT_EVENT_TOPIC_NAME =
         "icefacesContextEventTopic";
     public static final String RESPONSE_TOPIC_NAME =
         "icefacesResponseTopic";
 


The broadcast rendering topic is:

Code:
    public static final String RENDER_TOPIC_NAME =
         "icefacesRenderTopic";
 


As for combining the portlets into a single war, you've already noted the benefits if, as you've said, you have certain kinds of inter-dependencies between the portlets. Usually if you are doing IPC


Deryk Sinotte
Team Lead
ICEsoft Technologies, Inc.
 
Forum Index -> Async HTTP Server
Go to:   
Powered by JForum 2.1.7ice © JForum Team