Vaadin 7.1 - push implementation lacking

Vaadin 6 / 7 / 8
1

Hello,
I’m writing because i’m really unhappy about the quality of the implementation of server push.
Originally planned for vaadin 7, it has been pushed back to 7.1, which itself has been delayed for some time, so my company thought that vaadin 7 push was stable. Right? Wrong!

During the releases until 7.1.5 there were like five or six serious bugs in the push support (including fallback).
Some of these bugs were as grave as just locking the UI for the user - what a great UX, especially as our customers are not programmers but casual users.
But as we’re eager to deploy our push-enabled application to our customers, more bugs kept coming up, both found and reported by others and us.
Several of these can cause the UI to hang with the red loading indicator, which is just totally awful.
Another one leads to a huge memory leak (sessions for push-enabled UIs are never closed) which kills any server in production - I’m very happy we did not find out about that issue after deployment.

On one single issue, I’ve been debugging for a week, we eventually brought paid vaadin support in for 3 hours over the phone and remote desktop (3hours is 3*140€=420€, by far the most expensive phone call I ever did), which did not move forward the issue either.
We’re now really left with either just waiting until the core devs will fix the push problems (as no schedule is communicated, we can’t plan then, but just put releasing our work to our customers with push on hold) or fixing and patching the problems by ourselves as they occur - now that’s a great framework experience, if you’ve to patch your framework to fix framework bugs.

While this may just be a frustrated rant because I’ve invested over a week into debugging push related problems which did not stem from our application but from vaadin, I’m very discontent about the release of such a half-backed feature.
Yes, it’s great when it works, and it works mostly, especially if the end-user is using a websockets-enabled browser, I don’t deny that, but as IE9 and IE8 don’t support websockets, we’ve to consider that as well, and the streaming-fallback is way less tested than the normal websockets push channel. Having so many problems for quite some percentage of our customers is simply not acceptable.

Are there any plans to install better quality control at vaadin?
I really fear 7.2 or even 8, as, by experience, updating will break quite some functionality, and with 7.1 itself we didn’t even have a choice, as 7.0 was no longer supported.

Regards,
Cornelius

2

We turned off push for these very reasons. Oddly, it seemed okay on our developer PCs, but once we deployed we found issues even on modern browsers locking up with spinning loading indicators seemingly appearing out of nowhere (since the user took no action to induce it). But Vaadin was pretty rock solid in the 6.8 world, so we hope they’ll focus on more core widgets (add-ons are okay, but the upgrade to 7 showed their limitations over core capabilities) and fixing bugs rather than bogging down in architectural updates and trust their talents to get 7.x more solid.

3

Thanks or the heads-up. I was studying vaadin 7 and even bought the vaadin 7 cookbook in preparation of writing a new version for our Vaadin 6.8.12 web application. Pushing is a very big part of our application.
I guess i have to put this task in the freezer until a future date then… shame!

4

Cornelius R, Could you please, describe problems with Streaming Push mode and give a link to the tickets, because in our application we use also this mode because of the same reasons. Our application some times hangs with some XHR, but when in chrome console I update requests it passes. Of course it’s hard to reproduce, but maybe your cases could help me.

5

Our biggest push problem is http://dev.vaadin.com/ticket/12529. If you want to read the ticket, we only got to the core of the issue in comment #13 and #14 and later comments, before, we had some false suspicions of the cause of the issue.
The other important (still open) streaming issue is http://dev.vaadin.com/ticket/12567
and if you’re not on vaadin 7.1.5, definitly upgrade, as else there may be even more issues.

I definitly hope that the issues caused by push are getting fewer, because if it works, a push-enabled application is really great and feels superior to every non-push application (bye bye F5), so the direction of having push in vaadin core is definitly the right one!

6

Hi,

Sorry about the issues you are facing with push and Vaadin 7.1. When talking about almost all other features than push in Vaadin we have one major headache, which is the browsers and the differences between them. When talking about push on the other hand, we have browsers which work differently, we have two methods of transport which both work a bit differently in each browser and then we have the servers, all of which seems to have their own issues, both for streaming and websockets.

We have built our push support based on Atmosphere, which does a pretty good job of dealing with the various issues but like all products, it is not perfect. There have been some serious issues with the javascript from the 1.0 series of Atmosphere which Vaadin 7.1 is currently using. Today I think we have been able to fix most of the javascript issues except for the mentioned #12567 which currently in 7.1.6 prevent streaming from reconnecting when enough data has been sent through the push channel.

We have had some issues with auto-testing the push functionality like we auto-test other features because of the old (ancient) version of TestBench we were using in the core framework. As a result we have been forced to do manual testing instead which makes it much easier to overlook and miss things. Today, we have the latest TestBench version in use and are running automated tests for push in all our supported browsers and on all our supported servers and will notice possible problems much more quickly and reliably.

To deal with the remaining issues we have a team focusing on push stability for the following two weeks. The results of this should be visible in the 7.1.7 release. We are also working on upgrading to Atmosphere 2.0 for improved stability and better server support, but it is not clear today if it will be in 7.1 or if it will have to go to 7.2.

To reduce (or remove) the issues that proxies can introduce with streaming, we have also been thinking of making long polling another supported option for push when you do not have a browser (or server) which supports websockets. The upside of long polling compared to streaming is that long polling does not leave the HTTP request open after the response has been written (“pushed”) so there is no reason for a proxy to buffer it instead of delivering it to the browser.

7

Everyone needs to understand how difficult a job it is to implement push support for the large swath of browsers and servers. I’ve done two separate push add-ons for Vaadin 6 and neither are perfect. I’ve had to highly customize the solution for my company based on our usage (streaming-only, Tomcat behind Apache, FF & Chrome only). While I’ve got that nailed I couldn’t imagine having to do it for all browsers and servers, especially if you include IE in the mix. Just take a look at the Atmosphere google group and you’ll see the litany of problems related to push. Most are simply ignorance of how things work or how the push framework works and others are legitimate issues. For those of you still proxying behind Apache (my company included), STOP. If you want reliable push do NOT proxy behind Apache. Pretty much anything else will do: hipache, HAProxy, nginx, etc. Yes, the push bugs are frustrating but let’s all try and think about the level of complexity this feature requires without each of your individual use cases. I applaud the Vaadin team for finally tackling this issue and wish them the best. If I see any issues I’ll be sure to report them and try and fix them. Everyone else can help as well by contributing code and patches at https://dev.vaadin.com/review.

8

I came on the forums to check the status of this. We ran into a lof of these issues in the beta of 7.1 and abandoned it for production environment and stuck to icepush. Which has its own set of issues but they aren’t deadlocks/red spinners. We are considering moving to 7.1 seeing how it seems to have had a number of months of bake time. If people are still experiencing these issues I am little worried about moving to 7.1 and promising my customers stability. Lets see how it goes. push stability is hard but it is a serious issues for migration especially since we are asked to move away from 7.0.

9

I just stumbled across this thread but it matches my experience exactly as described here:
https://vaadin.com/forum#!/thread/3724024

I agree with some of the other commentors that push is really hard to get right across different browsers, servers, and network architectures and I think Vaadin is giving it a fighting try but it isn’t 100% yet. At this point my recommendation would be to use push in a controlled environment like an intranet where you know and control the exact client base and network configuration. Unfortunately that scenario doesn’t come up much.

For any internet facing application, polling still seems like the safest solution. Long-polling looks much more promising than streaming as a push solution given that it works in the confines of the HTTP request/response model (and compression and buffering and proxies and all the components involved in a round trip and etc, etc). I wish Vaadin had started with websockets and long-polling rather than streaming but they picked one and went with it.

I look forward to improvements in Atmosphere and Vaadin but for now, I’m not using push in production. It’s important to remember that if you weren’t using Vaadin, you’d be rolling your own solution using (most likely) Atmosphere and having to debug and fix these cross browser/cross server issues yourself. So as painful as 7.1 has been for some people, I still appreciate the number of hours Vaadin has put into this technology (for free for many of us!).

-mike

10

There is a way to use CometD for pushing in Vaadin 7, which does not rely on websockets. Components themselves will not trigger push on update, rather you have a handle to control when the UI gets to sync up (e.g. calling client.update())

There is an example here:
http://code.google.com/a/eclipselabs.org/p/vaadin-push-example/

Might be an idea if your clients are stuck with old browsers (IE8)

Ray

11

Ray, that’s an interesting idea that I might look into implementing if I get some time. It got me thinking that one way Vaadin could build a simple, reliable push mechanism would be to use long-polling to simply send a “dirty” byte to the client which could then do a normal poll round trip. This would make the implementation much simpler and Vaadin already has a proven and robust round trip client update mechanim (it’s what already happens when you use UI.setPollInterval). It would also eliminate all the issues with message sizes, special characters, buffering, etc.

Obviously it would introduce a few 10s of milliseconds lag because of the extra round trip but given the issues discussed in this thread it seems like a reasonable trade-off.

-mike

12

There are also two other options that we are considering for Vaadin 7.2

The first is to use long polling instead of streaming as the fallback mechanism. This transport mechanism has the theorethical drawback of requiring more TCP handshakes since a new HTTP connection is opened after delivering each message, but this does instead have the benefit of more “restarts” which means that it could work better with unreliable connections or if there’s some unsuitable proxy in between.

The other thing we are considering is somewhere between the current implementation that sends everything over the push channel and the suggested approach of just sending a ping over the push connection and doing everything else using the conventional transport mechanism. The idea would instead be to do anything initiated from the browser using the conventional XHR transport and then only using the push channel for events that are initiated from the server. This is covered in
http://dev.vaadin.com/ticket/12518
.

13

I’m glad to hear that you guys are looking into more (expanded) options in 7.2.

As for long-polling, it would be interesting to see just how much overhead it introduces. With keep-alive connections, I don’t think you would have a full TCP handshake but just an HTTP request and parsing of HTTP headers. Given that up until 7.1 most Vaadin applications were using polling, even extra TCP overhead with long-polling and non-persistent connections would be a big improvement.

As for 12518, I’m concerned that this could make things more complicated. As 12337 points out, there are already issues with message ordering and it seems like introducing two parallel communication channels could make that worse. At a minimum, debugging might get a little more complicated. One of the benefits of the “ping push” and “always client xhr” is that debugging is simple and supported in the developer tools in most browsers. With “ping push”, you’re really just making a smarter/faster polling client by telling it when to poll but all data is over easy to debug and reliable XHR request/responses.

I don’t know about everyone else, but I’ve found debugging websockets or HTTP streaming is a real pain right now as most tools just don’t support it well.

14

We also have a problem with the push impl in 7.1.7 - using the Java7 javafx WebView browser component and push set to streaming (no websockets) - it’s not working, requests run into a timeout and eventually after a long time some reply might come through. So more transport options are highly welcome! Any workaround for our problem would be much appreciated!

ps. not even using polling seems to help there :frowning:

15

Gosh, I discovered this thread after a
full week
 of trying to force the server to update the UI !!! Neither ICEPush nor Vaadin 7.1 push() work, it has been a journey of discovery through hell and back…

I am in the process of checking whether Vaadin is the right thing to use for a primarily
push-based
,
modal
web app. Neither push nor modality seem to have been
first-class design features
 of Vaadin. (E.g., in Java Swing – which is admittedly just for desktops – modality is a primary feature.) Would greatly appreciate thoughts and suggestions on this…

The specific problems I face: Vaadin push() essentially does

nothing

. ICEPush I cannot even get to work, because (i) I use UI and OrderedLayout, ICEPush seems to work only with Application and Window; (ii) I tried to switch, but importing com.vaadin.Application does not work! And, on the web, I cannot even find examples of ICEPush being used with UI and OrderedLayout, I see just one java example out there.

Thanks!

16

Push was definitely not a first-class design feature of Vaadin in the past because it really wasn’t feasable back in the days of IE6-8. Vaadin 7 rewrote much of the internals which setup the inclusion of push in Vaadin 7.1. While this thread (and a few others) point to bugs in the push implementation, the basic integration into Vaadin seems valid and is working in specific cases. If you’re using Vaadin on an intranet where you control the network connections and client browsers, push over Websocket is pretty darn good. However if you’re going over the public internet to unknown browsers, routes, load balancers, etc, you could run into trouble as Websockets isn’t fully supported everywhere and the HTTP streaming fallback can run into buffering/caching/delay problems.

As for modal web-apps, I’m not sure what you mean. Web browsers, JavaScript, and HTML are not designed to be modal so there isn’t much Vaadin can do there. Vaadin offers a “modal” window, but as the documentation points out, users can get around it by modifying the DOM and JS won’t block on a modal dialog like you might be familiar with in Swing. If you really need modality, you might need to look at non-web technologies.

It sounds like the add-on/examples you’re looking at are out of date. Vaadin 6 used Application and Window while Vaadin 7 uses UI and Window (different concept with the same name). I haven’t used ICEPush but you’ll want to look for a Vaadin 7 version if there is one.

-mike

17

Mike: Thanks for your reply.

A month later, I still face numerous problems with push, I anticipate switching to something other than Vaadin for the next version of my prototype code… Meanwhile, here is an incomplete list of problems:

I am on Tomcat v7.0, Vaadin 7.1, developing code in Eclipse Java EE IDE Kepler Service Release 1.

Push won’t work even when I access my app from the same machine it is running on (http://localhost/myApp)! A hack I found (after a lot of wasted time, that is) is to do the push from a child thread every time I need to push:
//--------------------------------------------------------------------
public static void myRefresh() {

    // call push() from a child thread
    // -- define thread
    Thread t = new Thread() {
        public void run() {
            myScreen.myUI.access(new Runnable() {
                @Override
                public void run() {
                    myScreen.myUI.push();
                }
            });
        }
    };
    // -- start thread
    t.start();

    // wait for push to be done..
    try {
        t.join();
    } catch (InterruptedException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

//----------------------------------------------------------------------

Obviously I don’t want to be forking child threads like this even in a beta deployment…

Second, even with the above, when I move the deployment from my machine to Amazon AWS, the push seems to fail, as the initial screen of my app shows up, but at the point where push() is called as above, the screen stops updating! And, the reason the initial screen shows up at all is another hack: I exit the main thread pretty quickly (i.e. after the first screen), and do the rest of my app in a child thread, and when the main thread exits, it pushes out the screen update!!

Third, perhaps unrelated to push, even on my local machine deployment, multiple simultaneous accesses to my app (e.g. from multiple browser tabs) does not work – it throws some error about connector ids! So, Vaadin restricts my app to one user at a time??!

Fourth, I get this truly random, annoying error message which prevents Eclipse from showing my app screen, I have to open my browser separately to view the app:

Failed to load the widgetset:
./VAADIN/widgetsets/com.vaadin.DefaultWidgetSet/com.vaadin.DefaultWidgetSet.nocache.js?1385485712490

Unless I click the error away, further screen pushes seem to stall. Oh boy!

BTW, by “modal” I mean Java Swing-like modality. I want to put up a window with a query and a bunch of choices, and the only thing the user should be able to do is answer the query before moving to the next screen of the app…when the user answers, I do some compute, then push out the next modal query window…

What lured me into trying Vaadin was the promise that one could develop a webapp as if it were just a desktop app. Clearly, the QA of Vaadin is not yet there Someone said Vaadin is free. Yes, it is, but that is only one part of the total cost of ownership – what about the time spent trying to get it to work?! And, the opportunity cost of not trying something else?

18

Intros,

Push definitely seems to work pretty well as long as you can make a websocket connection or you use http-stream and don’t have any buffering between the client and server (which is difficult to predict over the internet). You definitely shouldn’t need to spin up a thread just to do a push call. If you use automatic mode, you shouldn’t need to call push() at all.

Vaadin definitely supports multiple users for an application (and multiple tabs per user). In fact these very forums are a Vaadin application and there are a lot of simultanious users. You’d have to provide some more specifics on your setup and the errors you are see (in a different thread) and maybe someone can help you debug your configuration.

It sounds like however you have Eclipse launching the application Vaadin can’t find any of it’s resources under the /VAADIN/ path. Vaadin needs to be able to load its supporting JavaScript files, including the Widgetset. You might want to check the servlet mappings that Eclipse is using when launching the app.

As I mentioned before, Vaadin has “modal” windows but they are obviously constrained by web technology which means the user could get around them if they are crafty enough. This is a JavaScript/DOM limitation, not a Vaadin limitation. It sounds you would be able to implement your modal scenario without an issue.

We’ve found Vaadin to be incredibly reliable and robust. Overall, I would say it has greatly improved our productivity for web applications especially given the in-house Java expertise our team already has. I’d be interested in your results with other frameworks as it is always good to compare whats out there.

-mike

19

Attached is a log file from Tomcat on Amazon AWS (attached because cut-and-paste does not work when posting here). It is clearly a push() error… I will try to set push to automatic in web.xml and give it a try…

The Vaadin widgetset error is completely random… e.g. today it is working just fine, but it may stop working any moment.

I did see Mike’s post on another forum about getting push() to work. Now, my point is, if I have to get down to figuring out WebSockets, web.xml, etc etc, then where is the original develop-like-a-desktop-application that is promised by Vaadin?

Extremely frustrated…

13346.rtf (3.09 KB)