Hi Sven, thanks for the reply.
The problem is, that at the end of the request in onDetach wicket tries to write content of pages into the session (see storeTouchedPages in Stack-Trace), which is already dead. To identify if wicket needs to store content into session, it checked the Session.get() / ThreadContext.getSession() cached Session, which represents not the real last state of the session. When wicket then writes content into session, it look in the real dead session (getSessionStore().getAttribute call). So I don't know the right solution but I could not understand why checking state of session is done on a cached version while writing than is done on the real one. Does the process not to be consistent (check and write in the cached or check and write in the real one)? Kind regards PATRICK SCHWARZER SOFTWARE ENGINEER o +49 89 32175 655 TOMTEC Imaging Systems GmbH Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director: Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen [cid:image003.jpg@01D4EAC5.E4FEFCC0]<http://www.tomtec.de/> Hi Patrick, Wicket uses a temporary session if there's no container session, e.g. the latter has already expired. It's not clear to me why that's a problem for you. Best regards Sven Von: Patrick Schwarzer Gesendet: Mittwoch, 3. April 2019 13:27 An: 'users@wicket.apache.org' <users@wicket.apache.org> Betreff: Problem with ThreadContext.getSession when session dies Dear Sir or Madam, we identified an issue during request handling in Wicket 7.12.0 when session dies during processing. The problem is, that parts of the code accessing current session by calling Session.get() which then return a valid session cached in ThreadContext.getSession(). [cid:image004.png@01D4EAC5.E4FEFCC0] But when accessing an attribute of the Session, the code accesses the real session, which is dead and leads to an Exception. [cid:image005.png@01D4EAC5.E4FEFCC0] So we were a little confused why Session.get() and Session.exists() return valid results when Session is already dead. How we can avoid Session.get() and Session.exists() return valid results? Alternatively how we can ensure, that Request with cached Session is handled correctly? The stack trace of our problem: java.lang.IllegalStateException: org.apache.shiro.session.UnknownSessionException: There is no session with id [48cf6f39-9bf6-4b76-84cd-a106e707af63] at org.apache.shiro.web.servlet.ShiroHttpSession.getAttribute(ShiroHttpSession.java:133) ~[shiro-web-1.3.2.jar:1.3.2] getAttribute:286, HttpSessionStore (org.apache.wicket.session) getAttribute:743, Session (org.apache.wicket) << Why this is not accessing cached Session? getSessionAttribute:66, DefaultPageManagerContext (org.apache.wicket.page) getSessionAttribute:101, RequestAdapter (org.apache.wicket.page) getSessionEntry:414, PageStoreManager$PersistentRequestAdapter (org.apache.wicket.page) storeTouchedPages:438, PageStoreManager$PersistentRequestAdapter (org.apache.wicket.page) << Should this happen, when Session is already dead? commitRequest:193, RequestAdapter (org.apache.wicket.page) commitRequest:76, AbstractPageManager (org.apache.wicket.page) commitRequest:74, PageManagerDecorator (org.apache.wicket.page) commitRequest:270, PageAccessSynchronizer$2 (org.apache.wicket.page) onDetach:1798, Application$3 (org.apache.wicket) notify:105, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle) notify:101, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle) notify:120, ListenerCollection$1 (org.apache.wicket.util.listener) reversedNotify:144, ListenerCollection (org.apache.wicket.util.listener) reversedNotifyIgnoringExceptions:113, ListenerCollection (org.apache.wicket.util.listener) onDetach:100, RequestCycleListenerCollection (org.apache.wicket.request.cycle) onDetach:649, RequestCycle (org.apache.wicket.request.cycle) detach:594, RequestCycle (org.apache.wicket.request.cycle) processRequestAndDetach:297, RequestCycle (org.apache.wicket.request.cycle) processRequestCycle:261, WicketFilter (org.apache.wicket.protocol.http) processRequest:203, WicketFilter (org.apache.wicket.protocol.http) doFilter:284, WicketFilter (org.apache.wicket.protocol.http) internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core) doFilter:166, ApplicationFilterChain (org.apache.catalina.core) doFilterInternal:99, RequestContextFilter (org.springframework.web.filter) doFilter:107, OncePerRequestFilter (org.springframework.web.filter) internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core) doFilter:166, ApplicationFilterChain (org.apache.catalina.core) doFilter:61, ProxiedFilterChain (org.apache.shiro.web.servlet) executeChain:108, AdviceFilter (org.apache.shiro.web.servlet) doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet) doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet) doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet) executeChain:108, AdviceFilter (org.apache.shiro.web.servlet) doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet) doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet) doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet) executeChain:449, AbstractShiroFilter (org.apache.shiro.web.servlet) call:365, AbstractShiroFilter$1 (org.apache.shiro.web.servlet) doCall:90, SubjectCallable (org.apache.shiro.subject.support) call:83, SubjectCallable (org.apache.shiro.subject.support) execute:383, DelegatingSubject (org.apache.shiro.subject.support) doFilterInternal:362, AbstractShiroFilter (org.apache.shiro.web.servlet) doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet) invokeDelegate:357, DelegatingFilterProxy (org.springframework.web.filter) doFilter:270, DelegatingFilterProxy (org.springframework.web.filter) internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core) doFilter:166, ApplicationFilterChain (org.apache.catalina.core) invoke:198, StandardWrapperValve (org.apache.catalina.core) invoke:96, StandardContextValve (org.apache.catalina.core) invoke:478, AuthenticatorBase (org.apache.catalina.authenticator) invoke:140, StandardHostValve (org.apache.catalina.core) invoke:80, ErrorReportValve (org.apache.catalina.valves) invoke:650, AbstractAccessLogValve (org.apache.catalina.valves) invoke:279, RewriteValve (org.apache.catalina.valves.rewrite) invoke:677, RemoteIpValve (org.apache.catalina.valves) invoke:87, StandardEngineValve (org.apache.catalina.core) service:342, CoyoteAdapter (org.apache.catalina.connector) service:799, Http11Processor (org.apache.coyote.http11) process:66, AbstractProcessorLight (org.apache.coyote) process:868, AbstractProtocol$ConnectionHandler (org.apache.coyote) doRun:1457, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net) run:49, SocketProcessorBase (org.apache.tomcat.util.net) runWorker:1149, ThreadPoolExecutor (java.util.concurrent) run:624, ThreadPoolExecutor$Worker (java.util.concurrent) run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads) run:748, Thread (java.lang) Kind regards PATRICK SCHWARZER SOFTWARE ENGINEER o +49 89 32175 655 TOMTEC Imaging Systems GmbH Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director: Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen [cid:image003.jpg@01D4EAC5.E4FEFCC0]<http://www.tomtec.de/>
