<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 9, 2017 at 3:04 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">I'm migrating a legacy (circa 2005) n-tier JBoss 4 application to run in Wildfly 10. It was a struggle, but got pretty much everything done. We've been trying as hard as possible not to refactor logic/code/etc except in the cases where it is simply no longer compatible. The goal was to get the application working "as-is" in WF, then start tackling the job of breaking it apart and refactoring it into proper pieces.<div><br></div><div>The problem I have run into now is regarding session management. The application was designed to run on multiple nodes, but in standalone instances - ie: there is no shared memory, nor any distributed caches. So I'm trying to get my WF10 application to follow the same pattern (even though I realize all this exists in WF10 out of the box with Infinispan/etc).</div><div><br></div><div>One of the requirements is to only have a single session active for a user at any time in the "cluster". The JB4 application accomplished this by maintaining a local cache (HashMap) of session objects keyed by username. When a user logs into any node, a JMS message is broadcast to all the nodes to invalidate any session belonging to that user. The listener on each node then searches in his cache for a matching user/session object and does a session.invalidate(). Some extra logic is used for WeakReferences for the session objects (in case the session is destroyed by some other flow in the container).</div><div><br></div><div>As ugly as the solution was, we've tried to follow the same pattern under WF10. But this is failing in many different ways and reinforces my belief that it isn't the right approach. However, I would like to understand how/why this is failing.</div><div><br></div><div>My server configuration is using a <local-cache> for my "web" cache. So to me this means it is only local to the machine. But:</div><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><div>Undertow returns a different facade for each request. Undertow uses its internal representation of a session (io.undertow.server.session.Session) that is stored in the session manager, and wraps a facade around it (io.undertow.servlet.spec.HttpSessionImpl) that implements Servlet semantics.</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><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().<wbr>invalidate() throws <span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">IllegalStateException </span>as do calls to request.getSession().set/<wbr>getAttribute()</div></div></blockquote><div><br></div><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><br></div><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><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><div>This is a JVM bug. Which JVM are you using?</div><div><br></div><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.HttpSessionImpl#getSession() to return the Underlying Undertow session, although it should not be necessary.</div><div><br></div><div>Stuart</div><div><br></div><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><br></div><div><br></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-HOEnZb"><font color="#888888"><div><br></div><div>Eric</div></font></span></div>
<br>______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">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/<wbr>mailman/listinfo/wildfly-dev</a><br></blockquote></div><br></div></div>