Hi Patrick, On Thu, Apr 4, 2019 at 10:16 AM Patrick Schwarzer < patrick.schwar...@tomtec.de> wrote:
> 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). > I have the feeling there is some problem with Shiro here. What exactly is a "dead" session ?! Wicket uses HttpServletRequest#getSession(boolean) to get the underlying HttpSession. Depending on the value of the boolean parameter the Servlet container should: - if the parameter is 'false' then: -- if there is a session then it should return it -- if there is a no session then it should return null - if the value is 'true' then: -- if there is a session then it should return it -- if there is a no session then it should create a *new* HttpSession and return it So, I do not understand what Shiro considers as "dead" session. > > 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)? > Wicket stores the Wicket Session into a ThreadLocal, i.e. caches it. But any access to the HttpSession is via HttpSessionStore which uses the Servlet APIs. The Wicket Session itself is stored as an attribute in the HttpSession. > > > 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 > > <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(). > > But when accessing an attribute of the Session, the code accesses the real > session, which is dead and leads to an Exception. > > 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 > > <http://www.tomtec.de/> > > >
