(Edit: Some of the part i describe below is irrelevant. Check out the last post to see my latest results)
In my Web Application I want to reload the page when the server restarts. To accomplish that I disabled the SessionExpired Notification and also i added a Refresher (mainly for another reason but it helps in this case too). This setup worked perfectly in Vaadin 6.
In Vaadin 6 I disabled the SessionExpired Notification by Overriding getSystemMessages and then setting SessionExpiredNotificationenabled to false
Now when i migrated to Vaadin 7 I found out that you have to first create a Custom Servlet and then do the same thing. (Btw. I didn’t put PreserveOnRefresh in the UI class. Should i do this?)
In both cases i have the Refresher which polls the Server every Minute.
Back in Vaadin 6 when i then restarted the Server, after it got back up, it would automatically reload the page.
Now the problem is that when i do the same in the Vaadin 7 version an Exception get thrown in the Tomcat logs and the page doesn’t get reloaded. Only an Internal Error Notification pops up. The exception is:
javax.servlet.ServletException: No UIProvider returned a UI for the request.
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:312)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:201)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
936)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp
11Processor.java:1004)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoin
t.java:312)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source
)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I already looked for this exception in the forums but only found a thread about someone who had a Multi-Tab Application in which one of the tabs he had ?restartApplication in the URL. That’s why i looked through my code and browser-URL’s twice but never found a ?restartApplication.
Does anyone have an idea on where this Exception could come from and how i can resolve it?
I just tested adding @PreserveOnRefresh but when the Application/Refresher tried to pull while the server was down and then pulls the server again when it’s up i get the exception.
Can somebody at least point me into the direction where the exception gets caused.
This problem makes my application currently nearly useless as it needs constant maintenance whenever the server restarts.
After looking through the forum a bit i saw that someone said you have to add the heartbeatinterval so i tried that:
When the server gets pulled before the heartbeat invalidates the session the exception doesn’t occur. The application just keeps going what means that even the Communication Problem Notifications remain on top of the screen.
When the sever gets pulled afterwards the exception occurs again.
This way this still isn’t really an option for me because:
The time the server is down sometimes can largly vary. Sometimes the server is down for only several seconds when a new version of a Vaadin app gets uploaded but sometimes when server is undergoing maintenance it might be down for one or more hours.
Even when the server comes back in time the communication problem notification shouldn’t be there. Just disabling it is also not an option because this would mean that the page gets reloaded as soon as the next full minute is reached.
Is there any solution to my problem? I start to think that i have to stick to Vaadin 6 for a while if that’s really a bug.
I again made a bit more testing and found out that the Exception even gets called when i don’t disable the SessionExpiredNotification. To test this I changed my web.xml so that now it doesn’t use the CustomServlet anymore but instead the standard VaadinServlet. Then i tested my application/UI:
Start Server
Go to application page
Stop Server
Wait till first Communication Problem Notification pops up.
Start Server again
Wait for next Server request
→ Internal Error (No UI provider returned a UI for the request) instead of Session Expired Error
PS: Exception only occurs when the server is not started from eclipse but for example in my case from a local tomcat.
PPS: Only happens on one Application (Vaadin 7, Refresher)
I did a bit of digging into the VaadinServlet class where the exception gets thrown and it seems like the Refresher Add-On fires a UIDL when the Session is expired what causes the findUI method to not return a UI using the given UIDL and current (new) session.
As a result the VaadinServlet.service method throws the exception.
Is there any way to avoid this? Maybe through a CustomServlet, UIProvider, UI Extension (instead of the Refresher Add-On),… ?
This sounds indeed like something that Refresher might be responsible for. Technically speaking, the Refresher just calls the server with a set interval. If the session gets expired, Refresher doesn’t take that into account, and still tries to send data to the server. As the server is restarted, it tries to send data to Vaadin with an invalid session key, and Vaadin doesn’t appreciate that.
One fix would be to try to listen to when something goes wrong on the server side (session expires, other connectivity issues), but I don’t think there’s an API for that, so that would need to be “hacked” by hand.
The real issue, however, is that I probably will stop maintaining the Refresher altogether as Vaadin 7.1.0 gets out. In addition to server push, which often can replace what people are doing with Refrehser, it actually has Refresher’s abilities built in ( UI.setPollInterval() ). That’s already in beta1, if you want to try that out.
Thank you so much for your answer Henrik.
I will try it immediately using beta1 and i will report back when it’s done compiling my widgetset
I will try Polling and Threads because i don’t think Push would work in my scenario. I would think using push the session would expire immediately when the server is down.
Although i’m a bit sad that refresher won’t be continued in future (was very easy to work with the RefreshListeners) I like that it’s now implemented in the normal Vaadin framework.
Thanks you again,
M.R.
PS: I just tested it and the exception “disappered”. Although one thing is a bit weird. When the server comes back there is no Session expired message being fired. It looks like the session is kept alive through the restart but i think I can work with that.
Yeah, people have been liking the RefreshListener interface, but I’ve personally always been torn whether it was a good idea to introduce that, since it introduces semantics that I didn’t intend. But, as said, that’s mostly semantics.
The session being kept alive through restarts might be a feature in your server - some servers (e.g. Tomcat) try to serialize everything as the server is shut down, and then deserialize once it is started up again. So this probably isn’t something Vaadin is doing, but something Tomcat is doing, and it just stopped being broken, now that you stopped using Refresher
I just made a few changes and now the session expires propably and the page gets reloaded. Although i prefered the RefreshListener instead of the Threads i think i can get used to it
