<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 11, 2017 at 3:01 PM, Eric B <span dir="ltr"><<a href="mailto:ebenzacar@gmail.com" target="_blank">ebenzacar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Stuart, </div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks for the reply. A few followup questions if you don't mind.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-4080371439694904947gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>1) on any specific node, request.getSession() returns a different object for each request. The sessionId() remains the same, but the actual object ID changes. This implies that it is a different representation of the session object.</div></div></blockquote><div><br></div></span><div>Undertow returns a different facade for each request. Undertow uses its internal representation of a session (<a href="http://io.undertow.server.session.Se">io.undertow.server.session.Se</a><wbr>ssion) that is stored in the session manager, and wraps a facade around it (io.undertow.servlet.spec.Http<wbr>SessionImpl) that implements Servlet semantics.</div></div></div></div></blockquote><div><br></div></span><div>That's what I had assumed as well, based on the behaviour I had noticed. Thanks for confirming.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-4080371439694904947gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2) if I persist a local copy of the HttpSession object between requests (ex: in a static map) and invalidate the session using the persisted object, my request.getSession() object is not updated (ex: the invalid flag is still set to false), but the session is dead. Trying to call request.getSession().invalidat<wbr>e() throws <span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">IllegalStateException </span>as do calls to request.getSession().set/getAt<wbr>tribute()</div></div></blockquote><div><br></div></span><div>I guess this could be considered a bug in that isNew will not throw an IllegalStateException, which is the only place that the invalid flag is used without also consulting the underlying session, but you sound as if you expect the session to still work after it has been invalidated?</div></div></div></div></blockquote><div><br></div></span><div>No - quite the opposite actually. I'm expecting that all session objects to react the same after it has been invalidated. If I use one of the facades from a prior request to invalidate the session, I would expect that every facade would respect the same state. For instance, if I do the following:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Request 1:</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>// store a copy of the session object to be available in a later request</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>static Session cachedSessionObj = request.getSession();</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Request 2:</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>// invalidate the session from the cached object</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>cachedSessoinObject.<wbr>invalidate();</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>// get a new session</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Session newSession = request.getSession();</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div>I would expect that cachedSessionObj.getId() != newSessoin.getId().</div><div><br></div><div>However, the request.getSession() doesn't get a new session object. Rather it still returns the old (now invalidated) session object. So any logic that is dependent on having a fresh session object fails (since the session object is returned is actually the invalidated session).<br></div></div></div></div></blockquote><div><br></div><div>Once a session has been assigned to the request it does not change. This is a bit of a grey area.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>There is no requirement that the same session is represented by a single java object, and especially it in a distributed environment this is not possible. Even though we could keep the same facade around for all requests this can encourage people to write apps that rely on this behaviour, and also increases the likelihood that the facade will become tenured and require a full GC to be reclaimed. </div></div></div></div></blockquote><div><br></div></span><div>Understood.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-4080371439694904947gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>3) over time, my JVM will actually crash with an EXCEPTION_ACCESS_VIOLATION in a GC process. This always seems to correlate with a thread that is trying to do some session invalidation via the persisted session copy.</div></div></blockquote><div><br></div></span><div>This is a JVM bug. Which JVM are you using?</div></div></div></div></blockquote></span><div>I'm running Oracle Hotspot Java 8x64 on a Windows platform (server 2016). I've tried with both patch 131 and 151, and both exhibit the same behaviour. </div></div></div></div></blockquote><div><br></div><div>I would report it to Oracle. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>To implement this I would remove the WeakReference which will not work with Undertow's session management strategy, and instead register a listener to remove the session from the local map when it is invalidated. If you really want to access the underlying Undertow session you can call io.undertow.servlet.spec.<wbr>HttpSessionImpl#getSession() to return the Underlying Undertow session, although it should not be necessary.<br></div></div></div></div></blockquote><div><br></div></span><div>I've already removed the WeakReference as soon as I noticed that the session facade returned by Undertow changed at each request. I am using a session listener to remove it from the local map when it is invalidated, but I need an ability for an JMS listener to be able to invalidate a session object based on an id it receives.</div><div><br></div><div>How can I access Undertow's SessionManager from within my application? Is there any way I can retrieve it from the CDI? I tried adding the io.undertow.core module to my jboss-deployment-structure.<wbr>xml, but yet I can't access it via injection or via: CDI.current().<wbr>getBeanManager().getBeans(<wbr>SessionManager.class); in both cases it is unable to find the SessionManager class. Is there some other way I can access it/retrieve it from within my application? </div></div></div></div></blockquote><div><br></div><div>You can do io.undertow.servlet.spec.ServletContextImpl#getSession(java.lang.String) to get an arbitrary session.</div><div><br></div><div>If you want the actual SessionManager you would need to call io.undertow.servlet.spec.ServletContextImpl#getDeployment().getSessionManager().</div><div><br></div><div>Stuart</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div>Thanks,</div><div><br>Eric</div><span class="gmail-"><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-4080371439694904947gmail-"><div dir="ltr"><div></div><div>Is anyone able to explain this behaviour? Why is the session object always different between requests? Shouldn't it be the same request? What is Undertow doing with the session objects between requests? Is the Undertow object being passivated in some way and my attempt to invalidate if from within my cached version causing this kind of access violation? Is my cached object referencing memory that has been cleared by the GC (ex: does the request.getSession() object only a WeakReference to the actual Undertow object)?</div><div><br></div><div><br></div><div>Finally, what would the recommended approach be to doing something like this? Using a distributed web-cache is unfortunately not an option at the moment. So give that, is there some way to access the Undertow session manager directly?</div><div><br></div><div>Thanks for any insight. I thought we had a functional solution but in production (under real load), the intermittent JVM crashes are telling me that our solution is broken.</div><span class="gmail-m_-4080371439694904947gmail-m_-7919415190237888510gmail-HOEnZb"><font color="#888888"><div><br></div><div>Eric</div></font></span></div>
<br></span>______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a><br></blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>