ICEfaces has been developing a push server for a long time. Now it’s been released for non ICEfaces integrations. The available link includes integration bundles for GWT, Wicket, SpringMVC, Javascript, jQuery and Protorype.
The ICEfaces push server works fine. Current release is in Alpha 3, but the base Push server has been working for a long time. Probably Vaadin could integrate it.
Aniceto
Can someone provide some input on how hard this would be to integrate into vaadin on our own, in case we want this functionality? From what I read on the forums and book of vaadin, I know other gwt ui widgets aren’t too hard to integrate. Is that the case with this one? Vaadin newbie here still trying to learn the ropes
Thanks.
Given that ICESoft has licensed ICEPush with MPL, this is a really interesting idea because the technology has been used with technically rather similar UI framework (ICEFaces) in the past. Still, it would be really interesting to understand the motivation for ICESoft for releasing ICEPush and integrations for competing technologies like (Wicket, GWT, …). Any ideas?
Also does anyone have experience on how well ICEPush scales and what it requires on the server-side? Any estimates on the code-side (JavaScript) on the client?
I think you should check out
the ICEPush add-on for Vaadin
I just created (still very experimental). Seems to work very well actually!
Wow… That was fast.
Unfortunately the demo is down:
javax.servlet.ServletException: Failed to load application class: org.vaadin.artur.icepush.demo.IcepushdemoApplication
com.vaadin.terminal.gwt.server.ApplicationServlet.init(ApplicationServlet.java:71)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:619)
Some typos fixed and the demo should now work. It’s not very impressive though. Need to figure out something better.
that was fast… guess that answers my question. 
Thanks.
If you did the same demo, but forked off a few native windows (mimicking several applications waiting), you would be more convincing. This is certainly one case where polling is perceived as being wasteful. I have one such application where several components in several applications (several users actually) are using the refresher trick. Can’t wait to try your component!
Dear Artur,
is ICEPush based on WebSockets?
If not, on what technology it is based to keep connecton to browser?
How to do this scenario that it will automaticly push data to browser it there will be any on the sending queue (server -to-> client)?
I think if it could work like that it would be better than Refresher. Do I think correctly? Or maybe I’m wrong and ICEPush it designed for totally different use case?
Thanks,
Artur.
“ICEpush is based on a lightweight, asynchronous Notification Core that leverages long polling over HTTP, and standard Browser capabilities to enable Ajax Push in any Java EE deployment.”
See http://www.icepush.org/ if you need more information about the underlying technology.
From a Vaadin application developers point of view it works just like the Refresher. Changes made on the server side are in a “pending” state and when you call push() you tell the client that there are changes wating on the server side. The client will then fetch these changes in the same way the Refresher would at the given intervals.
It should indeed perform the same task as Refresher but without the need of defining an interval (no waiting for the interval to expire before getting updates) and without the need of polling. It is also compatible with all browsers Vaadin supports.
Thank you for the answer.
Do you provide some kind of API to easyli connect vaadin sending queue with ICEpush to send eveny pending events immediately? For example .connectWithVaadinSendingQueue( true ); ;).
Does ICEpush has some other use cases than beeing Refresher replacement ??
Artur, can you write how ICEpush works under the hood??
Is it a kind of script on client side that works just like a Refresher and in givern interval asks server for new data?
Or maybe it works somehow on http 1.1 whitch odes not close socket?
Or maybe it using this trick with downloading image whitch never ends???
Thanks:).
Calling the push() method for the component causes the updates to be sent
I think the ICEPush guys are much better at describing the technical details of ICEPush. The notification protocol is described in their wiki: http://wiki.icefaces.org/display/PUSH/Notification+Protocol+Overview
It is based on long polling and uses XHR, basically keeps a request open until an event takes place on the server side. After an event it closes and reopens the connection. If you open e.g. http://artur.virtuallypreinstalled.com/ICEPushChat/ with Firefox when you have Firebug open you can see how it works.
Thank you for your answer.
Can somehow Vaadin server side outgoing queue be connected with .push() method to be called when any data will be put on it ??
Since you didn’t give any other scenario to use ICEpush I think connecting outgoing queue with .push() is the most popular way.
I don’t know if it is correct way to use ICEpush add-on in Vaadin but maybe someon can put a simple example how to connect server side sending queue with push() method. Arthur coud add it to add-on as a simple method. When there will be any pending data/event on sending queue, push() will be automaticaly executed.
And one more question. I read that ICEpush has some kind of heartbeating (ping-pong to check if connection is stable). Does it gives this result that if I close browser then server will get .close() event after few seconds??
I don’t quite see what you mean by “server-side queue”. The usage pattern for “push” that I have seen is as follows:
Some event happens without user A intervention, for example: a previously started task running in the background is finished, or some other user B is changing the database in a way that affects what user A should be seeing.
The server side for user A is listening to such changes. When a change occurs, the server-side wants to update the components that user A is looking at on the client. It modifies the content of the various screen components (exactly as in the example provided with the add-on). When it is done, calls push().
In that sense, the queue is implicit. There is one pusher for the window. You can do several updates, to the various components of your window, before calling push(). push() causes the pending requests for the window to be processed by the client. There is no need to “queue” requests.
Thank you for your answer.
I thought that there is on server queue with events waiting for sending to the client. If client make any (inter)action then all those events goes to browser.
If there is not sending queue in GWT on server side then I don’t know how to easyli connect automaticly called push() with any data waiting to be send to the browser.
As I understand it will be very nice to call just label.setValue( “new value” ) and forget about calling push() every time.
The very last point is valid.
There should be some kind of automation, that every call to setValue() force to write “push()” (just like every object returned from the method should be checked it it is null).
When I will know Vaadin better I will try to find one common place to install push() and I will publish it here, on the forum :).
Quick hint for that last point:
You could add a RepaintRequestListener to each component that’s added (with a ComponentAttachListener perhaps), and call push() when repaint is requested. Just remember to remove all listeners when the components are removed as well 
(Can’t think of easier way to know when something needs to be repainted right now - adding just one listener to Application that would receive events for all repaintRequests would be handy in this case…)
Best Regards,
Marc
Edit: This whole push-thing is something we should probably consider integrating better in 7