Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to bypass FakeHttpSession #1269

Closed
wolfie opened this issue Sep 5, 2013 · 10 comments
Closed

Add an option to bypass FakeHttpSession #1269

wolfie opened this issue Sep 5, 2013 · 10 comments

Comments

@wolfie
Copy link
Contributor

wolfie commented Sep 5, 2013

We at Vaadin would need an option to bypass the usage of FakeHttpSession. For example, when using Atmosphere with Jetty, no FakeHttpSession is created, but one is created when running Tomcat 7.

I've understood that FakeHttpSession is used because the HttpSession can expire at any time, while it doesn't concern WebSockets. In our case, this isn't an issue, since we have an XHR heartbeat that keeps the HttpSession alive at all times.

FakeHttpSession makes access to the actual HttpSession instance very hard in our situation, thus we can't e.g. invalidate the HttpSession, or store any session attributes, since FakeHttpSession doesn't bridge those calls to the actual HttpSession.

@wolfie
Copy link
Contributor Author

wolfie commented Sep 5, 2013

linkback to our corresponding ticket: http://dev.vaadin.com/ticket/11721

@jfarcand
Copy link
Member

jfarcand commented Sep 5, 2013

@wolfie pull request welcomed :-) FakeHttpSession is used to support WebSocket only because, for example, Jetty doesn't allow accessing the HttpSession for a WebSocket where Tomcat/GlassFish allow it.

@jdahlstrom
Copy link
Contributor

@jfarcand Do you mean Jetty throws an exception or something?

@wolfie
Copy link
Contributor Author

wolfie commented Sep 5, 2013

(sorry, having internet problems, i hope i'm not double-posting this
comment).

We tested with jetty-8.1.9.v20130131 by bypassing the creation of
FakeHttpSession in AtmosphereRequest.cloneRequest, and passed the native
HttpSession there instead. We were able to invalidate the session
successfully, while using WebSockets, without any apparent problems.

Can there be other problems along the way? Like, issues with sharing
session objects with other users, or some such?

On Thu, Sep 5, 2013 at 5:19 PM, Johannes Dahlström <notifications@github.com

wrote:

@jfarcand https://github.com/jfarcand Do you mean Jetty throws an
exception or something?


Reply to this email directly or view it on GitHubhttps://github.com//issues/1269#issuecomment-23870840
.

Henrik Paul

@jfarcand
Copy link
Member

jfarcand commented Sep 5, 2013

@wolfie Sound like Jetty's changed the behavior of the HttpSession. If you try with Jetty 7.6 and up, does it give the same result? The Jetty team may have changed the behavior, so we must make sure we aren't breaking older version. I'm all for removing this hack, but originally it was added for a good reason :-) Thanks!

@skaddy
Copy link

skaddy commented Sep 7, 2013

I've got an issue which may be related, I've got a 20-minute timeout for session in web.xml.
Desired behaviour should be that if clients stay on the web page (with a websocket connection opened and making GETS to Atmosphere Servlet) the session should never expire while if the user leaves the page (no request anymore), after 20 minutes the session should be expired.
Unfortunately even if the connection is opened and the clients exchange message (i've also tried an XHR heartbeat) the session expires anyway after 20 minutes.

I'm using Jetty 9, Atmosphere 1.1.0 with Hazelcast Broadcaster

Thanks!

@jfarcand
Copy link
Member

jfarcand commented Sep 8, 2013

@skaddy Share your test case :-)

@skaddy
Copy link

skaddy commented Sep 9, 2013

@jfarcand which is the most suitable way of presenting a test case?

@jfarcand
Copy link
Member

jfarcand commented Sep 9, 2013

@skaddy A simple Maven project I can run. Thanks

@jfarcand
Copy link
Member

Ok fixed in 2.0. @wolfie @jdahlstrom Do you need a backport? Please make sure you test properly. Like I said, early version of Jetty were'nt allowing access to HttpSession after the handshake. Same for Tomcat, but this may have been changed. I will test Tomcat 7 tomorrow and switch the behavior as false in case it works with 7.0..4x and up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants