How would you go about implementing ajax push, for example https://atmosphere.dev.java.net/ . I cannot wait to use such feature.
Hi,
Currently there is no such integration available, but you could try Henrik’s
Refresher
, which is an invisible component that polls the server at configurable intervals.
This has been discussed a lot, but there are other very nice features like wysiwyg, drag-n-drop, etc competing the same resources…
Some links to discussion:
http://vaadin.com/forum/-/message_boards/message/81684
http://vaadin.uservoice.com/pages/20474-general/suggestions/385149-simple-push-solution
http://vaadin.uservoice.com/forums/20474-general/suggestions/456824-comet-server-push
and
http://dev.vaadin.com/ticket/111
I dont find the #111 ticket in any roadmap, it would be of interest to know how serious vaadin is about such a future that is a deal breaker for some usage cases.
More Importantly its something ordinary people are becoming more and more used to and hence expects any modern service to have (instead of basic polling).
Whats a realistic time frame for a scalable solution for server push, or at least a pluggable framework so we can attach our own solutions ?.
I will have to look into this myself later this spring, i cant do with standard polling (several K SSL users with multiple frequent push needs).
I do have my own websocket server impl with java clients to toy around with, but due to the current state of browser support its not usable in the near future (.
Its mainly to explore better scalability by designing differently then the standard concepts normally used in todays server products:
With minimized context switches due to using load balancing among many selector threads as natural work queues for execution of non blocking logic at both protocol and service level the overall server throughput is increased.
Implementing threadpools using LinkedTransferQueue from doug lea cvs or jdk7 (java 1.6 compatible) gives a good boost to the scalability compared to the standard (synchronized) designs that all products seem to use today.
Pool is still resizable, it just requires an external call to do it.
The min max pool size concept is ditched since its a very contra productive design that only brings costs without true benefits.
#111
is not in roadmaps, but it should be. Unfortunately there has always been “more important things” that has pushed it from being included in roadmaps.
Implementing push with Vaadin should not be very hard - all server-side events are already collected in application servlet and you could just add a “trigger” there to send them to client using some existing push implementation. Creating a general implementation that would make everyone happy is a lot harder thing to do as some push configurations are not really easy to deploy (like one ones where one should deploy a separate push server to subdomain in order to go around IE6:s limit of two concurrent http connections per domain).
Also, if you want to take a peak - Vaadin version 3 (called Millstone back then) has a server push implementation. It was a bit unreliable with some browsers and were left out from version 4.
I’m new to Vaadin but from my understanding the current state of affairs is that to get server-generated events some sort of polling is required. Well, that’s OK… i.e., it’s not the end of the world for many applications and suffices as a workaround until some form of “official” server push is implemented.
But given this state of affairs, Vaadin should have a more explicit way to do polling. From what I can tell the only way to do it now is the “progress meter hack”. Instead of hacks buried in the forums, why not create a first class API for polling?
For example, something like:
/**
* Instances cause clients to poll for server-generated events at a fixed interval.
*/
public class ClientPoller {
/**
* Create a poller that will poll every {@code millis} milliseconds.
* Initially this instance will be stopped.
*
* @param millis polling interval in milliseconds
*/
public ClientPoller(int millis) {
...
}
/**
* Get the currently configured polling interval.
*
* @return polling interval in milliseconds
*/
public int getInterval() {
...
}
/**
* Change the currently configured polling interval.
*
* @param millis polling interval in milliseconds
*/
public void setInterval(int millis) {
...
}
/**
* Start polling. Does nothing if already started.
*/
public void startPolling() {
...
}
/**
* Stop polling. Does nothing if already stopped.
*/
public void stopPolling() {
...
}
/**
* Poll once for updates. Can be used for "ad hoc" polling.
*/
public static void pollOnce() {
...
}
}
In the implementation you would have a singleton class on the client that “collapses” the polling demands from all active
ClientPoller
instances. So for example if widget A creates and starts a 5 second instance, and then widget B creates and starts a 7 second instance, you would still end up polling only once every 5 seconds.
Should I file a feature request? 
Any news about PUSH??
As I read it was planned but there were ‘more important things to do’.
Are there any changes? Plans?
Thanks,
Artur.
No plans for push, yet :(
Thats not good.
PUSH will give to Vaadin extra power, whitch it has already a lot :))
Are there any roadmap or blog to read what you work on or what will be added in near future and what is general the direction of project??
Thanks,
Arthur.
Roadmaps are done at least twice a year. They will be published at
vaadin.com/roadmap
.
Glad to see “an official push add-on implementation” added to
Milestone Vaadin 7.0.0.alpha4
which is due in 4 months.
That’s great. Even so, I still think an integrated client polling solution would also be helpful. Sometimes maintaining push is too heavy when you have a large number of clients.
I’m disappointed that the simple idea proposed in this forum thread (and as
ticket #4056
) has yet to be implemented.