Push got broken from beta 1 to final 7.1

Hi,
I set up a small push application mainly based on the related blog entry. It worked just fine with 7.1.beta1, but after migrating to 7.1. final push is broken, components are not updated any more. Anything I have to adjust to get that fixed?

Regards,
Rudolf

Quite a few push bugs were fixed between 7.1.0.beta1 and 7.1.0 final, including several workarounds for bugs or other issues in various servers, browsers, third party libraries and mobile devices.

Did you follow
this blog post
or some other one? At least the tutorials under “Communication and Push”
on this page
should be up to date for 7.1.0. If you are using GlassFish, see also
this page
.

If you still have problems with those tutorials, please provide more details about the server and browser used (including the exact version numbers), how push doesn’t work, how you try to use it and what is in the logs.

Thanks for quick response.

Yes, my demo is based on the mentioned blog and I am not using Glassfish. I have a thread that calls an update method for every 5 seconds. Update method itself gets the UI via UI.getCurrent() and pushed random values with access and a new runnable which updates a label value.
With 7.1. label gets updated once, so the first value is shown. While update method is called again and again from the thread, label get’s not updated anymore. This is different with 7.1.beta1, where label value gets updated with every call of update method.

Which server and exact server version are you using? Which browser and version? Is there anything in server logs?

Maybe it would also be good to check the debug window (add ?debug to the URL) - the info tab there should show the communication method that is actually in use (XHR/websockets/streaming/XHR with polling) and the log and communication tabs could point to some possible problems.

Unfortunately it’s still not working. I copied example from http://demo.vaadin.com/book-examples-vaadin7/book#advanced.push.basic to be absolutely sure that source is not the problem. I deployed on tomcat 6.0.29 as well as tomcat 7.041, both not pushing.

Couldn’t find anything from ?debug mode, where can I find the communication mode there? Communication tab just mentiones two responses.

The following is from final 7.1 application log, haven’t seen that while running 7.1.beta1:

Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework addAtmosphereHandler
INFO: Installed AtmosphereHandler com.vaadin.server.communication.PushHandler mapped to context-path: /*
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.DefaultBroadcaster
INFO: /* support Out Of Order Broadcast: false
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework autoDetectWebSocketHandler
INFO: Auto detecting WebSocketHandler in /WEB-INF/classes/
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework initWebSocket
INFO: Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework autoDetectContainer
INFO: Atmosphere is using async support: org.atmosphere.container.Tomcat7AsyncSupportWithWebSocket running under container: Apache Tomcat/7.0.41
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework configureAtmosphereInterceptor
INFO: Installed Default AtmosphereInterceptor [Android Interceptor Support, SSE Interceptor Support, JSONP Interceptor Support, Atmosphere JavaScript Protocol, Browser disconnection detection]
. Set org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults in your xml to disable them.
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
WARNING: No BroadcasterCache configured. Broadcasted message between client reconnection will be LOST. It is recommended to configure the org.atmosphere.cache.UUIDBroadcasterCache
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
INFO: Shared ExecutorService supported: true
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
INFO: HttpSession supported: true
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
INFO: Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
INFO: Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
INFO: Using Broadcaster: org.atmosphere.cpr.DefaultBroadcaster
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework init
INFO: Atmosphere Framework 1.0.14.vaadin3 started.
Jul 04, 2013 8:13:24 AM org.atmosphere.cpr.AtmosphereFramework interceptor
INFO: Installed AtmosphereInterceptor Track Message Size Interceptor using |.

On Tomcat 7.0.41, websockets should work and the log entries look ok to me, although I am not an expert for push.

The communication method (transport) is shown on the info tab of the debug window along with versions etc.

Which browser and version are you using?
Do you have the setting asyncSupported on in your web.xml or WebServlet annotation?

I have the same problem. It appears to work but after some time the entire page freezes. If I refresh the screen, it runs for a few more seconds.

My code:


  class ClockThread extends Thread {
  @Override
  public void run() {
  
        while (true) {
        
            // Do initialization which takes some time.
            // Here represented by a 1s sleep
            try {
                Thread.sleep(10000);
            } catch (InterruptedException e) {
            }

            // Init done, update the UI after doing locking
            try {
                                access(new Runnable() {
                                    @Override
                                    public void run() {
                                        // Here the UI is locked and can be updated
                                        hora.setValue(formatHora.format(new Date()));
                                    }
                                });
                        } catch (UIDetachedException e) {
                                // Si se produce una excepción es que se ha cerrado la sesión, finalizamos el bucle
                                break;
                        }
      
        }
  }

I’ve tried with Tomcat 7.0.41, 7.0.38, and Jetty 8. I use Chrome as explorer.

So finally I could resolve this issue. Seems that updating an existing project in eclipse does not work fine for beta1 to final (I changed version in ivy.xml). I set up a new project, copied sources and resources, now it’s working fine.

I can’t do that! It’s a huge project! :[

If it does help for some, you could update the Vaadin Eclipse plug-in, create a new Vaadin 7.1 project in Eclipse, copy the relevant bits of ivy.xml to your old project and try updating the build path order if necessary.

The interesting parts are all the Vaadin dependencies as well as the configuration list and the arguments of the dependencies tag (defaultconfmapping). There is also a new “nodeploy” conf that needs to be added to the Eclipse project build path. Some of these might already be ok in your project depending on the Eclipse plugin version that was used to create your project.

If it helps anyone out, I just recently updated my project version from 7.0.5 to 7.1.0 and it seemed that it broke a lot of components in my project. It seemed that I could go to 7.1.0.beta1 but 7.1.0 would not work. So I ended up updating my eclipse plugin, cleaned all my Ivy cache and did a fresh resolve, and finally recompiled the theme and widgetset and after that, everything worked out fine.

I have started a new project, and it has the same problem. At a random amount of time, it loses the connection between the client and the server, and I only receive this message:


jul 10, 2013 12:44:47 AM org.atmosphere.cpr.DefaultBroadcaster perRequestFilter
WARNING: Request is not longer valid d100d714-bda5-4c20-b1fb-271f87c730a7

I’ve tried both with Jetty 8 and Tomcat 7.0.41.
Tomorrow I’ll try with Tomcat 7.0.42, but I’m getting tired of these problems :frowning:

I had similar problems, I observed one time that tomcat seemed to use IPv4 for Client->Server and IPv6 for Server->Client when using WebSockets. This induced problems. Check the tomcat logs if that is the case for you. Running tomcat with -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true ended this behavior and push worked better.
Anyhow we have still similar problems on SOME of our machines where as it is working perfectly on other machines. We have not yet found out what the reasons for this are.