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.
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.
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.
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 :).
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
Is there any reason not to push systematically on every component update ? The bytes have to go to the client anyhow, and the channel is open. In other words, make pushing the default instead of pulling.
Someone more familiar with ICEPush will correct me if I’m wrong, but I’m under the impression that the add-on works by sending a nudge to the client when the server side push() is called, and the client will then perform a normal server roundtrip that pulls any pending changes and renders them. This would mean that it’d be more efficient to send the changes in batches instead of doing that roundtrip for every component tree change.
It’d be trivial to add a thread in the server that just calls push() periodically, but I don’t think this has any real upsides over client side polling with eg. the Refresher add-on. The current ICEPush add-on allows the developer to control the “transaction” and “commit” the changes to the client in suitable batches, which I think is the best option even if it requires some legwork for the developer.
I suspect you are right “push()” is in fact “nudge to pull”.
But the “suitable batch” is what I’m after.
Is there any reason to batch at all? If I am updating several components in response to an event, it is probably easier to update each component and nudge right away (this keeps the logic simple). In that way I don’t have to keep track of whether I am done updating the components on a window (and wait until I am done with the window to issue the nudge).
Indeed, that is how it works. ICEPush just provides a notification channel from the server to the client.
I can think of cases where you do not want to push after each component update, for instance when adding components to or removing components from a layout. Wouldn’t look very good if the intermediate state was shown to the end-user.
When I find some time I will investigate how ICEPush could be better hooked into the Vaadin core. Vaadin provides a RepaintRequestListener which is fired every time a part of a component is updated. By listening to this ICEPush could know what is going on and for instance when there has been no repaint events for X ms it could push the changes automatically. Then you wouldn’t need to call push() yourself, unless you absolutely want to push the changes immediately when they have been made.
Please, do that !!! ICEpush would become then as great extension.
If you need consume one (or more) thread consider method that allow user to provide it own instance of java.util.concurrent.ScheduledExecutorService (or maybe it is already available in server side Vaadin?). For example this will allow me to connect threads that you will need with my thread pool for Scala actors.
I am unable to get the demo to work from source. (checked out from the incubator)
(there is no such class in the source).
I am also unable to get my own code to work. I have followed the instructions and changed the servlet as indicated.
Things appear to be working on the server side. For example, I got a meaningful message when trying to push without adding the pusher to the main window, and adding the component as in the demo made the error go away.
My problem is that pushing doesn’t. I was setting the value of a label before pushing, no changes. I tried replacing the component as something more drastic, no changes.
When inspecting the page with Chrome, I see the inclusion of the icepush.js (but no apparent javascript invocation to that code).
As a last ditch attempt, I added the two lines found in the demo’s widget set definition, such that the end of my file is now
[code]
<inherits name="org.vaadin.artur.icepush.IcepushaddonWidgetset" />
<inherits name="org.icepush.gwt.ICEpush" />
<!-- adding support for icepush -->
<script src="icepush.js"></script>
[/code] (the bottom two entries were not present with automatic recompile)
All this under Vaadin 6.3.3.
So to recap:
Where can we find the current source to the demos
Is there a debugging setting I can turn on in ICEpush or your code to get more information as to why pushing doesn’t
There was a problem with the web.xml in the repository (referred to the wrong class). The correct demo class is org.vaadin.artur.icepush.example.ICEPushDemo, which the web.xml in incubator now also refers to.
What you should see with Firebug or another tool that displays the requests is
GET icepush.js → returns the icepush javascript
POST create-push-id.icepush
POST add-group-member.icepush
POST listen.icepush → This request should remain open until you call push() on the server side
