ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

That helps. I only have a guess at this point but I'm betting the threads used for rendering (both the one you created and the ones in the thread pool that the RenderManager uses) do not have the proper class loader set. When running Tomcat in non-embedded mode, when those threads are created, they'll nicely inherit the class they were created in which means they can find all the JSF jars. This also explains why the render can be run from the main execution thread. What we need to figure out is how to best pass the relevant information on to your thread (and the RenderManager's thread pool).

Is there a scaled down/simple version of your embedded Tomcat application that you can send to our support account:

http://www.icesoft.com/support/reqsupport.html

You mentioned that it was a new install of Tomcat but that you were running a few apps on it. Are you running those new apps on the new Tomcat instance? What types of apps are they? If they are JSF apps, are they using MyFaces because the sample wars come installed with Sun's JSF RI you might have an issue trying to mix-and-match.

I think the search is not working properly. I manually went back to page 10 of the forums and found the acegi thread so the info is still there. We'll get to work on sorting out the search issues.

I just downloaded a clean copy of Tomcat 5.5.20 and a copy of the ICEfaces binary bundle and dropped the auctionMonitor.war file into the webapps directory of Tomcat. I saw no exceptions and the application ran fine.

The type of errors that you are seeing typically indicate that a core JSF class called FactoryFinder cannot actually find the various JSF factory implementations (ApplicationFactory, LifecycleFactory, etc) on the classpath and when code attempts to actually use the factory, an NPE is thrown.

Can you provide any more information about your environment? Can you get a non-ICEfaces JSF page to work?

Try checking out the Developer's Guide on using the RenderManager. You'll need to add a server-side call to cause a render to occur for the client. The RenderManager provides an API for doing this sort of thing for individual users and for groups of users. You can also use an DelayRenderer rather than creating a Thread for each potential user that logs in.

My first guess would be that your CollectionAdminRenderer bean is never referenced on the page (ie there is no component that requires it to retrieve a value) so it is never created. If that is the case, there are a couple of options.

One is to put some sort of reference to the bean on your page(s) so that they are actually created for each request and the RenderManager then will get set properly.

The other is to programmatically create a RenderManager singleton somewhere in your code rather than use faces-config.xml. The faces-config.xml method is a good way to properly scope (application) the RenderManager but it's entirely feasible to create it yourself. Just make sure there is only one for your app.

There are currently only three types of server side renderers to choose from:

1) On Demand - requests a render once, right away.
2) Delay - requests a render once after some set time period.
3) Interval - repeatedly requests a render at a regular interval.

The first two only run once so are not a consideration for your concern. The Interval renderer will run infinitely as long as there are valid users in its collection. If a client's session expires, then an exception will be thrown (FatalRenderingException) that is catchable by your bean (the on that implements the Renderable interface). At that point it can remove itself from the renderer group and, if desired, stop and dispose of the renderer.

So the short answer is no, the thread used by the renderer does not need to run indefinitely but there is some work on the developer's side that needs to be done.

Deryk

The proper way would be to call clock.dispose() if you are done with the renderer. We use a fixed size thread pool for the rendering so the threads won't really go away but the clock should stop intermittently trying to render the various clients.

There is a known bug in the current release (1.1) if you try to re-use an existing renderer. This is fixed in the upcoming release which should be in early to mid November.

Deryk

The heartbeat mechanism on the client-side will try to abort and re-establish the server-push connection within the constraints of its configured parameters (the interval between heartbeats and the number of heartbeats). You can set low interval and high retry values to help cover your specific set of use cases. In the interest of full disclosure, I should mention that the reconfigurable heartbeat is *only* available in the ICEfaces EE (Enterprise Edition). The CE (Community Edition) uses some default non-configurable values for the heartbeat (3 beats, 20 seconds apart). Once this has been exhausted then the "Connection Lost" status is reached and the client stops trying to re-connect. From there, you'll need to reconnect manually (refresh the page). So I believe ICEfaces EE should handle what you need from the client side.

The server side story is a bit different. As updates are available for the client, they are pushed into a queue and sent when the server-push connection is available. The number of unsent responses in the queue is currently not configurable but when it reaches it's maximum capacity, no more server-push responses will be attempted. So you can continue to send server-initiated changes to the client in the hope that the problem is transient and that it will reconnect but, from the server side, the algorithm to determine this is not currently available for modification or configuration.

Deryk

1) This first scenario seems very odd to me since an implementation of AbstractMap without a put() method wouldn't seem all that useful. From what I can see in our code, the implementation used is a HashMap so it's strange that this exception is thrown. I'm not sure the best way to troubleshoot this. What JDK are you running your version of WAS on?

2) This looks like it's caused by a corrupt .jar file. How are you creating your EAR and WAR files? Are you using Ant or IBM tools or something else? Can you confirm that the archives can be successfully un-jarred manually (ie jar xf demo.jar)?

3) This one looks like it can't find the clock page. Not sure if you changed anything since you sent us the demo code but in the version you attached to a previous post, the file was not clock.jsp but clock.jspx and the URL should look like:

..../demo/pages/standalone/clock.iface

instead of:

..../demo/standalone/clock.iface

Deryk

The heartbeat mechanism is configurable in that you can control how much time between each heartbeat and how many attempts it makes before the connection is considered lost. It will attempt to re-connect each time it does this. Having the heartbeat go every second is going to look a lot like polling and brings up your earlier concern but I'm probably not fully understanding the requirements of your application.

Of course, if the server is actually unreachable, ICEfaces won't be able to help you out. It's good...just not that good.

Deryk

Just a quick test on that #4 scenario. WAS seems to require getters and setters for all bean properties - even if they are not called. So add a public RenderManager getRenderManager() method to your bean (and do the same for any other properties that might require them) and try it again.

I'll take the demo you supplied and try it in my environment to see what happens.

Deryk

So I just ran the demo and I see the same problem as you described in scenario #4. You'll need to be get through all the getter/setter additions before we can see if there are any more obstacles.

I assume one other problem will be IBM's XML entity resolution which insists on going out on the Internet to resolve the namespace?

Deryk

I've finished running Auction Monitor (one of the sample applications that comes with the ICEfaces 1.0.1 distribution) without any adjustments to the class loading or removal of WebSphere specific JSF libraries. I created a new app server profile before doing this to ensure I was running a "stock" version of WAS 6.0.2.

I did try switching between "Parent Last" and "Parent First" but it seemed to work either way (as long as I restarted the server in between).

I'm running on 6.0.2.13 so I'm not sure if this has anything to do with it. I didn't find anything in the Fix Notes to indicate it would:

http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg27006876

I checked the IBM JSF implementation version of the libraries and they are 1.0 (ie they haven't been updated by any fixes).

The stack trace in your log does seem to indicate some sort of class loading issue for sure but I'm unable to duplicate it in my environment.

1) Are you able to run one of the sample applications provided with the ICEfaces distribution (like Auction Monitor)?

2) Would you be able to send us a copy of your .ear or .war file for evaluation by our support staff?

One other theory is that IBM's FacesContextFactory is being registered last and therefore becoming the first factory in the delegation chain (a JSF design that seems a bit odd to me but that's just my opinion). It might be possible to specify the ICEfaces factory in the faces-config.xml file of the application. Add something like this:

<factory>
<faces-context-factory>
com.icesoft.faces.context.FacesContextFactoryImpl
</faces-context-factory>
</factory>

Deryk

Hey, Thomas

Now let's see if I understand your concern correctly.

Our server-initiated rendering is also referred to as "Comet" or long-polling. It's not polling in the conventional sense in that we send a request every xx number of seconds and return the response immediately, whether or not there are updates.

Instead, ICEfaces, using XmlHttpRequest, opens up a connection to the server. The request is "blocked" (held open) without sending back a response until something on the server changes and determines that the client needs to be updated. It then packages up the response (the incremental changes that need to be made) and sends it to the client. The client takes those changes and updates the parts of the page as necessary. At this point the client sends another request to the server that gets "blocked" waiting for the next server update. So the polling happens on whatever interval the back-end updates occur. If you're updating the time every second, then it'll will appear to be polling every second. If you update every minute, then you'll only get a request/response cycle every minute.

We do also have a "heartbeat" type mechanism to ensure the connection to the server is still alive and valid so you will see the occasional "ping" message as well. The timing and behaviour of the heartbeat is configurable to allow for high-latency connections.

As far as actual socket connections go, this is managed by the browser but in most cases, these are HTTP 1.1 (persistent) connections so the actual connection itself remains open and the subsequent HTTP requests are sent over the same connection (again, this is up to the browser).

What it sounds like you might be looking for is a single request with multiple responses (http://ajaxpatterns.org/HTTP_Streaming) which we do not do. I'm not aware of which, if any, frameworks do it this way but I certainly haven't surveyed them all. In any case, it's not clear that this approach would help you much with a high-latency connection anyway.

Deryk