Cannot invalidate session from push request

[vaadin-bot]

Originally by @Artur-

---

As push uses a copy of the real HTTP session with no link to the real HTTP session it is impossible to invalidate the HTTP session during a push request. Closing the VaadinSession works ok.

---

Imported from https://dev.vaadin.com/ issue #11721

[vaadin-bot]

Originally by @wolfie

---

Please provide more information on reproducing this issue.

I was able to invalidate the session by running the master branch of Vaadin 7.1 on Jetty, and calling the following code in a separate thread, wrapped in the UI.access call:

VaadinSession.getCurrent().getSession().invalidate();

This code has no immediate effect, however, but interacting further with the Application does result in an "Session Expired" error notification.

In my test case, I did notice a potential problem where calling getPage().reload() did not refresh the page when done as a push command, but I'll file a separate bug about this once I've verified that this isn't a side-effect to any session invalidation problems.

[vaadin-bot]

Originally by @Artur-

---

I think this is a problem only with Tomcat and possibly some other server. It originates in the fact that the HTTP session is copied for some servers (at least Tomcat 7) because the server does not share the HTTP session between the servlet and the websocket server.

[vaadin-bot]

Originally by @wolfie

---

Problem now confirmed with at least Tomcat 7.0: attributes written to a HttpSession when having a @Push-enabled application will not "stick", if the write cycle is initiated by a Button.ClickListener. Problem goes away for me when the annotation is removed, or I'm using Jetty. Investigating further.

[vaadin-bot]

Originally by @wolfie

---

Filed an enhancement request #1269 with Atmosphere

[vaadin-bot]

Originally by @wolfie

---

There is no reliable way to fix this directly. There were a few options we considered:

1. Check that the latest versions of servlet containers would allow us to simply bypass the usage of FakeHttpSession and operate directly on the HttpSession.
2. Add some kind of mechanism to link the initial HttpSession with FakeHttpSession.

We deemed that these solutions would be too hazardous to implement, since the long-term side-effects in all corner cases are unknown. Some quick prototypes seemed to work, but we had no chance of verifying those. Also, we would've needed to diverge our fork of Atmosphere even further, which we are very reluctant to do, considering we still need to keep up to date with the upstream in the future.

This ticket and a related #11808 (both which stem from very related issues - not being able to access the original http session/http request objects) will be closed with the resolution "wontfix". Instead, this issue was decided to be fixed with the help of #12518 (so you should follow and vote on that ticket instead).

We don't want to fix the individual symptoms, but we'd rather work around the issue by providing a more rigorous solution to this, and any related problems.

[vaadin-bot]

Originally by @Artur-

---

Re-tested this with the following results on 7.2-SNAPSHOT:

• Tomcat 8 (8.0.3) does not use a FakeHttpSession so this works properly
• Tomcat 7 (7.0.52) requires FakeHttpSession or you will get an immediate session expired
• Jetty 9 (9.1.3.v20140225) does not use a FakeHttpSession so this works properly
• Jetty 8 (8.1.9.v20130131) does not use a FakeHttpSession so this works properly

Thus this is a problem limited to using websockets with Tomcat 7.

[vaadin-bot]

Originally by @Artur-

---

In Vaadin 7.6 you can use transport=WEBSOCKET_XHR to get around this limitation