I'm having some serious issues with the Server Push support in Vaadin 7, and it's proving difficult to pin down the problem. I've followed all the steps in the Book of Vaadin on enabling server push, including adding the vaadin-push.jar file to WEB-INF/lib, adding the "asyncSupported = true" parameter to the #WebServlet annotation, and adding the #Push annotation to the UI class. (I've also tried specifying the equivalent in the deployment descriptor.) I also added the org.atmosphere.useWebSocketAndServlet3=true property to the catalina.properties file of my Tomcat 7 server, as suggested in https://vaadin.com/wiki/-/wiki/Main/Working%20around%20push%20issues.
I found the Server Push support to be very quirky, making it difficult to identify the problem. For instance, when developing code, the server will often not automatically re-start; only recognizing new code when I close the browser (not just the browser window), stop the server and re-start Eclipse; missing any of these steps will result in the Server Push not working. Note that this issue only occurs when Server Push is enabled. I read something about sessions not expiring when push is enabled (https://vaadin.com/forum#!/thread/3576361), so maybe that's the reason..
I often encounter suspicious log messages:
Mar 02, 2014 9:25:45 PM com.vaadin.server.communication.PushHandler$3 run
WARNING: Could not find push connection to close: 38450652-2a2b-4221-8300-8313e9c4779a with
transport WEBSOCKET
Mar 02, 2014 9:25:45 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load
java.nio.ByteBuffer.
It does seem that the Atmosphere is finding the async support:
INFO: Atmosphere is using async support:
org.atmosphere.container.Tomcat7AsyncSupportWithWebSocket running under container: Apache
Tomcat/7.0.47
I also found this error; don't know whether it indicates a serious problem (haven't tried resolving it, since I don't want to get into the Atmosphere stuff):
WARNING: No BroadcasterCache configured. Broadcasted message between client reconnection will be
LOST. It is recommended to configure the org.atmosphere.cache.UUIDBroadcasterCache
That said, Firefox works quite well with the Server Push, while Chrome has problems and IE spews errors (surprise!). In particular, Chrome often takes quite a while to communicate a UI interaction (e.g., button push) to the server, whereby a spinner (changing color from yellow to orange to red) appears at the right top. IE simply updates the wrong UI components when multiple windows are open. So, as long as every user employs Firefox there's no problem, but I can't possibly assume that.
I came across this post, where developers vented their frustration on the feature: https://vaadin.com/forum#!/thread/4040408. This is quite a recent post, so it doesn't sound too promising.. The only reason I need the Server Push feature is to allow the ChatBox add-on (https://vaadin.com/directory/-/directory/addon/chatbox) to update in real-time.
Any ideas? Has anyone gotten these kinds of errors and managed to get some workaround? Or even better, has anyone gotten the ChatBox add-on to work with the Server Push?
Thanks,
William
Try Again
Web Push is still a young technology, especially the WebSocket variety. Tomcat for example replaced one WebSocket implementation with another. Vaadin’s adoption of the Atmosphere library and all the other work in Vaadin 7 are relatively new. Much has improved in the months following the posting of this Question. I suggest giving Push another try.
Use the latest versions of your web server. For example, both Tomcat 7 & 8 and Jetty have made significant changes in their support of Push and WebSocket.
Use the latest version of Java 8 and Vaadin (7.3.7 now).
No Need For setPollInterval
No need to call UI::setPollInterval as was mentioned in the comments above. That feature uses only one approach to Push.
All you need is the #Push annotation. And a Thread, or better, a ScheduledExecutorService to update the data for display in your app. Using the #Push annotation engages the Atmosphere library. Atmosphere tries multiple techniques of Push, starting with WebSocket, and automatically uses other techniques as a fall-back.
Working Example
I recently (2015-01) posted a working example of Push working in Vaadin 7.3.7 as an answer to another question. My example is purposely minimal, using a single file to replace the MyUI file’s content in a new default Vaadin app project.
Related
I had been happily using Java live reload while debugging my Vaadin application over the past few months.
Today, after I started my browser and directed it to my locally running Vaadin application I got a popup in the lower right corner stating:
Java live reload unavailable. Live reload for Java changes is currently not set up. Find out how to make use of this functionality to boost your workflow. Read more
Clicking onto the read more link (pointing to 'https://vaadin.com/docs/v14/flow/workflow/workflow-overview') just brings me to a "404 Page Not Found" error page.
So - two or actually three questions:
what could cause my live-reload functionality go missing? I am using MS Edge and the Live-reload plugin is enabled (and it used to work until yesterday).
where has the page gone explaining how to set that up?
and finally: Any idea, what to check or fix to get this working again? I consider that pretty essential functionality for efficient UI development!
For question 2, you can find the documentation here: https://vaadin.com/docs/v14/guide/live-reload
I am building a static app with PouchDB on Google AppEngine.
When I open the site in a browser window, it is showing a version I uploaded several hours ago.
If I open the site in an incognito window, the updated version is displayed (therefore I don't think it is actually an error in the console).
I put a new version number in app.yaml
I have migrated all traffic to the new version.
I have cleared my cache, deleted cookies, checked my application data, everything. I even reinstalled Chrome and Firefox.
I updated my Python version and my Google AppEngine Launcher yesterday; the problem pre-dated that update.
Also: just discovered that if I go to the URL of the updated version
http://4.[app-id].appspot.com, it displays the correct, updated version.
This is happening in Chrome, Firefox, and Edge.
Edit: probably should have mentioned that my site uses Service Workers and IndexedDB. I assume my service workers are caching the previous version, but I would have thought that Ctrl + F5 would clear the cache and show the new version.
I think it must be the Service Workers caching the pages (which is, after all, what they are supposed to do). This is actually really annoying when you are developing though.
A guy called Rich Harris has documented this behaviour and some workarounds on a Github Gist.
Reloading the page doesn't behave as you'd expect
If you make a change to your service worker, then reloading the page
won't kill the old one and activate the new one (it detects the change
by requesting the service worker file each time and comparing the old
and the new byte-for-byte), leaving you somewhat confused as to why
your changes haven't taken effect. This is because the old window is
never actually closed, meaning there's never a time to swap them out –
you need to kill the tab completely then reopen it.
Or you can have the browser do that for you by going to the
Application tab in devtools (in Canary, not stable Chrome yet), going
to the Service Workers section, and checking 'Update on reload'.
UPDATE (13 Nov 2017): This functionality is now available in Chrome, so you don't even need to download Canary.
And here's which bits of the application cache to clear:
Is start (Dart server side framework) auto-refresh when one of our source code changed (just like PHP)?
Is bulls_eye, bloodless and express too?
or if they are not, is there any Dart server side framework that able to do that (edit code, then test on the browser, without needing to restart the dart/server program)?
Currently this is not yet possible in Dart. If you change the code you have to restart the app.
I wouldn't expect this to work anytime soon.
A main feature to make this possible is to manipulate the code at runtime. This is planned but as far as I know not yet started.
EDIT
The above mentioned feature is necessary when you want code to be updated without loosing the current state of the application but that is usually not so important on the server because it should be (mostly) stateless anyway.
In Dart there's no need to restart the server app when only the client part changes.
If you really just want to restart the entire server when the code changes you should be able to do that by yourself. Create a console app that loads the server app into an isolate (spawnUri) and watch the source directory for file changes. In the case of a file change shutdown the server-app-isolate and create a new one.
I think my issue is somehow related to the issue described in the post https://stackoverflow.com/questions/12526125/monodroid-wcf-request-response-of-2-asynch-requests-got-mixed. If it is so, the question is when it's going to be fixed. The MonoDroid 4.2.6 seems still having the issue.
My exact problem is this. In the main action I start 5 async service requests. 4 service requests to one service and 1 service request to another service. Before sending the requests I add [ServiceName]Completed event listeners. The event listener for the service with one call is fired and two of the other event listeners are fired but they are fired twice. First time with the .Result equal null and the second time with the valid .Result object. The other two event listeners are never fired. On the service side I correctly receive all 5 requests and the service sends back all the responses.
It is rather difficult to isolate the problem. Two many things were changed in the environment. The last version that worked was running on the Windows 7, using MonoDroid 4.2.4 and VS2010 was used for compiling the project.
Now the problem is revealed under Windows 8, using MonoDroid 4.2.6 and VS2012 was used for compiling the project.
It does sound like this is a bug pure and simple in the Mono code.
Looking at https://bugzilla.xamarin.com/show_bug.cgi?id=7200 it claims this is now available in 6.0.2 in the Beta channel.
If you are still seeing the original problem, then contact Xamarin via Bugzilla - and via support#xamarin.com too if needed - it looks like they are keen to resolve the issue.
Please try Mono for Android 4.2.7, which has a number of related bug fixes.
I'm new to dealing with cookies and not sure if my code or maybe Indy version is the problem based on researching other posts.
Using Delphi 2010 and Indy 10.5.5.
Have set up a cookiemanager at design time. I can send an initial login request (using the POST method) to the server that is successful (get a "success" code back from the server app) and the cookie manager shows that it has accepted a cookie from the server.
When I try to reply to the server (again using POST) to get the next set of information, I get an error code back from the server app which indicates an authorization failure and I'm being told by the server tech support people to check the cookie being sent with the reply.
How can I check the contents of the cookie header that is being sent back to the server?
Also, in another post I saw that Indy 10 IdCookieManager.pas and IdCookie.pas have been updated in 2011. Should I update my Indy to the latest version as this might be my problem?
Thanks in advance.
Here is some more info:
Thank you for your previous assistance; I appear to be getting closer to reinstalling Indy10.
I purged my system of all Indy stuff except the most recent version (10.5.8) which I downloaded yesterday. [Actually I just moved the old stuff into a directory with an unusual name.]
Now I get a clean compile on all 5 packages.
I was able to add the two main packages (the ones starting with dcl) to my program's project list.
But I get "[DCC Fatal Error] E2202 Required Package IndyCore not found." when I try to compile my main program.
I tried removing and reinstalling the dcl packages to my project. When I removed them, I got the message that IndyCore and 3 other packages would also be removed - so it seems to know that dclIndyCode140 uses IndyCore140.
I've added some directories to my search path and tried placing the 5 bpl's in different directories. None of that had any effect and at this point I am stumped.
Ideas? Suggestions?
Steve
Upgrading to the latest release is definate recommended. Links are on Indy`s website. Yes, cookie support was broken in earlier Indy 10 releases but it working again now.
As for your other question, to see what TIdHTTP is sending, you have a few choices:
Look at the TIdHTTP.Request.RawHeaders property after sending a request.
Attach one of Indy's TIdLog... components to TIdHTTP, such as TIdLogFile, and look at the output.
Use an external packet sniffer, such as Wireshark.