Hi, This fix seems to address only particular case when attribute is expired. But this will not work in generic case, right? For example, if attribute is put and removed explicitly, listener will not be invoked. I don't think we should rely on underlying session here, the logic has to be properly implemented in Ignite's session implementation.
BTW, if you're working on the ticket, please assign it to yourself and follow the process. More details here: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute -Val On Wed, Jul 5, 2017 at 3:25 AM, yucigou <yuci....@gmail.com> wrote: > Ignite WebSessionV2 uses genuineSes as the original HttpSession. > > Therefore, when setting an attribute or setting the maxInactiveInterval, > Ignite should tell the original HttpSession about it. > > Otherwise, when the web container (such as Tomcat) thinks that a session > expires, or is invalidated, or a session attribute gets removed, etc., > session attributes' HttpSessionBindingListener's valueUnbound callback > function will not get fired. > > So once the original HttpSession gets updated with the session attributes > and the maxInactiveInterval, the web container will transitively trigger > the > session attributes' HttpSessionBindingListener's valueUnbound callback > function when a session expires, etc. > > (By the way, tested with our app, and our issue is fixed: > https://github.com/apache/ignite/pull/2243) > > > > > > -- > View this message in context: http://apache-ignite- > developers.2346864.n4.nabble.com/It-seems-WebSession-s- > removeAttribute-does-not-support-HttpSessionBindingListener- > tp19184p19480.html > Sent from the Apache Ignite Developers mailing list archive at Nabble.com. >
