ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Is there anyway to control the verbosity of the logging on the browser side for an application using icefaces/icepush? I'd like to be able to change it when needed for firebug output. I believe there is a dropdown in the logging window that you can bring up using the ctrl-shift-t key combination, but that can't be brought up without remapping the ctrl-t comment in chrome or firefox (for opening a new tab) to a different key combination.

Thanks for any help!

Actually on a push render, all my component classes get destroyed and recreated with chrome and they lose their state (saveState and restoreState don't ever seem to get called), but when I run with firefox, none of my components get destroyed and recreated, so their state remains intact and the app functions properly.

Out of curiosity, has anyone had any issues with Chrome related to ajax push? My web app doesn't have any issues under firefox, but with Chrome, things start to act funny on the server side. When running under chrome (my app only have one view, which uses the panelStack component), one of my component classes seems to be destroyed and recreated during each push that happens to the client (I have a logging statement in the constructor). This causes the component to always thinks it's uninitialized. When I run the same app in firefox, the custom component class is always reused. Does anyone know what the behavior in icefaces should be for a custom component when a client is having updates pushed to them (while they aren't navigating)? Shouldn't the component always be reused? Why would a component get destroyed and recreated on each push? My request backing beans seem to be hanging around like I would expect. Is there anything known that would cause differences in server side behavior with chrome versus firefox? I had to turn off concurrent views in my app, because using Chrome, it appears beans no longer get destroyed on the server side, only when the session is destroyed. When using firefox, the beans get disposed when the view gets destroyed... lots of weirdness happens when I hit the app with a chrome browser.

Hopefully this makes sense...

Has anyone setup the push-server with a reverse proxy, such as with Apache HTTP server? We had it working with 1.7.2 by simply mapping the async http server context (forget what it was offhand) in the reverse proxy configuration. I have changed that to /push-server for the push-server context, but now non of the server pushes work like they did with the asyc http server. It seems as though the push-server URL always returns a page of 0 length. I'm not sure why since the push-server context should work the same through the reverse proxy just like the async http server, but for some reason it's not. I'm hoping someone has tried this successfully, I don't think we have a misconfiguration, but I don't see any other reason it wouldn't work.

Thanks!
Ryan

I had parameters for the old ahs in my web.xml that I needed to remove. That was why. All you should need to do in order to get the push-server working is to deploy the push-server war to tomcat. I'm not sure if it's a requirement, but I turned on the nio connector in tomcat. The push-server seemed like it needed that turned on in order to work, but I don't think the docs said definitively that it must be on (though I think it did say that it should be turned on).

I think I have it resolved.. there were a few parameters in my web.xml that were causing some issues. I think things are working correctly now regarding ajax push.

Thanks.

Yes, it's deployed..

I did clear all my cookies and all that... since I haven't been going to the same web app with 2 different tabs.. that seems to be helping a lot... still investigating...

Actually I think this issue is caused if you have two browser tabs opened to the same icefaces webapp but different pages... can anyone on the icefaces team confirm that for me?

In one of my other non-portal apps, when I go to the page the first time (with the push server enabled), as soon as I client an icefaces control on the page, the app times out. This is the only thing in my firebug log for that app:

------------------------------------
POST http://localhost:8090/salinaweb/block/send-receive-updates
http://localhost:8090/salinaweb/block/send-receive-updates

200 OK 5ms icefaces-d2d.js (line 19)

ParamsHeadersPostPutResponseCache Response Headers Request Headers

<session-expired/>

------------------------------------

So there appears to be only one receive updates and all it contains is a <session-expired/>.

I had my app successfully working with icefaces 1.7, but since I'm moved to icefaces 1.8, I've been having a lot of problems with pushes not happening anymore, as well as my icefaces sessions timing out. Here is a snippet from firebug showing some issues I'm having in a non portal environment:

[window.0yRE#1.async-connection] blocking connection not initialized...candidate for its creationicefaces-d2d.js (line 18)
[window.0yRE#1.async-connection.blocking] [7468548] : receive [200] OKicefaces-d2d.js (line 18)
[window.0yRE#1.async-connection.blocking] [7468548] : connection closedicefaces-d2d.js (line 18)
[window.0yRE#1.async-connection.heartbeat] pingicefaces-d2d.js (line 18)
[window.0yRE#1.async-connection.ui] [2785762] : send asynchronous POSTicefaces-d2d.js (line 18)
POST http://localhost:8090/salinaweb/block/ping
http://localhost:8090/salinaweb/block/ping

200 OK
69ms icefaces-d2d.js (line 19)
ParamsHeadersPostPutResponseCache
Response Headers
Request Headers

[window.0yRE#1.async-connection.ui] [2785762] : receive [200] OKicefaces-d2d.js (line 18)
window.console is undefined
[Break on this error] (47 out of range 2)
blank (line 47)
[window.0yRE#1.async-connection.heartbeat] pong losticefaces-d2d.js (line 18)
[window.0yRE#1] connection in troubleicefaces-d2d.js (line 18)
[window.0yRE#1.async-connection] retry to connect...icefaces-d2d.js (line 18)
[window.0yRE#1.async-connection] closing previous connection...icefaces-d2d.js (line 18)
[window.0yRE#1.async-connection] connect...icefaces-d2d.js (line 18)
[window.0yRE#1.async-connection.blocking] [4184967] : send asynchronous POST

Also, my app is using the push-server and successfully detects the push-server on startup.. I think I'm going to try without the push server to see if I get any better results.

I was able to resolve the problem, I can only hypothesize that it was caused by an OOME due to classloading memory requirements increasing in the portal. Once I upped the memory, it seemed to resolve the issue. Unfortunately the UI seems to seriously spike firefox when doing manipulations.. I guess they must be using a new jquery that is much more intensive or something. Oh well, it's livable.

Or maybe it is.. I think some other issues can affect whether or not this works properly in 5.1.2... I guess I'll just keep testing it.

I'm using liferay 5.1.2 and this doesn't appear to be fixed.. I'm guessing it's still a liferay issue? I guess I'm gonna have to go back everything out to 5.0.1 again.

I finally figured out the issue with this. For some reason, it was choking because I was referencing a javascript file with this fix in it. As soon as I inlined it back inside my portlet template, the error goes away. I'm not sure why it didn't like my script include since it's the same way I include every other javascript. Oh well, I don't care, it works now which is good enough at this point.