Hi Nachos, sorry not to reply before now.
OK, so I don't have an immediate solution for you, I'm afraid. But I can talk about what's happening, and perhaps we can work out some sort of way forward. ~~ (As I'm sure you've worked out/know already), we bind the IsisSession (a wrapper for a JDO PersistenceManager, equivalent to a JPA/Hibernate Session) on a thread-local. Within the IsisSession we can have multiple transactions. When the request is finished then the session is (meant to be) unbound from the thread. In Isis the terminology for "open" and "close" rather than "bind" and "unbind". The exception happens because Isis is trying to "fail fast" if it finds that a thread that already has an Isis session attached to it and tries to open a new one. ~~ I have two theories as to why we could encounter this situation. The first is that the previous request on that thread (which might have taken place several seconds or even minutes before) has not properly closed that thread. The second is that actually the current request is somehow trying to open a session twice... not exactly a race condition but something similar. Given your stack trace, which is being thrown from the IsisSessionFilter (whose job it is to set up a session for the request), I doubt it's the second situation. ~~ Two options going forward. The first is to work around it, by removing the "fail-fast" check. As you can see, the behaviour of Isis is pluggable; we have an SessionClosePolicy. We could, without too much work, introduce a configuration property to allow auto-close policy to be enabled. Second option would be to try to get to the root cause of why the problem is occuring. For that we will need to enable some logging, I think. You'll see that there are lots of debug statements in IsisSessionDefault and also PersistenceSession. There's also, in IsisContextThreadLocal#debugData, some code that dumps all the sessions held by thread. It also might make sense to put together some sort of performance load test to see if we can make the problem easier to replicate? Let me know your thoughts... Cheers Dan On 14 May 2015 at 16:22, Nacho Cánovas Rejón <[email protected]> wrote: > Hi everybody. > > There is some time since my last message..., but I'm been following all > your advances reading from mail and talking to Óscar and congratulations > for your work. > > I'm having a problem with sessions since I updated to DataNucleus 4, and I > did some research looking for the problem. > > This is the exception: > > java.lang.IllegalStateException: Session already open and context not > configured for autoclose > at > org.apache.isis.core.runtime.system.context.IsisContext.applySessionClosePolicy(IsisContext.java:182) > at > org.apache.isis.core.runtime.system.context.IsisContextThreadLocal.openSessionInstance(IsisContextThreadLocal.java:145) > at > org.apache.isis.core.runtime.system.context.IsisContext.openSession(IsisContext.java:275) > at > org.apache.isis.core.webapp.IsisSessionFilter$SessionState.openSession(IsisSessionFilter.java:396) > at > org.apache.isis.core.webapp.IsisSessionFilter$SessionState$1.handle(IsisSessionFilter.java:316) > at > org.apache.isis.core.webapp.IsisSessionFilter.doFilter(IsisSessionFilter.java:409) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) > at > org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) > at > org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) > at > org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) > at > org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383) > at > org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) > at > org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606) > at org.apache.tomcat.util.net > .JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:724) > > Is a random exception and I don't know how to reproduce it, because it can > appear in any moment. > > When it appears, if we try to get the resource from the thread where it > happens, always receives HTTP 500 code status. So it seems to be caused > because a session wasn't closed properly. > > I looked to ISIS code, but I din't find some change specially in > configuration that may has changed. > > This is my web.xml code: > / > <filter> > <filter-name>ShiroFilter</filter-name> > <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class> > </filter> > > <filter-mapping> > <filter-name>ShiroFilter</filter-name> > <url-pattern>/*</url-pattern> > </filter-mapping> > > <context-param> > <param-name>configuration</param-name> > <!-- > <param-value>deployment</param-value> > --> > <param-value>development</param-value> > </context-param> > <context-param> > <param-name>deploymentType</param-name> > <param-value>SERVER</param-value> > </context-param> > <!-- > - > - config specific to the restfulobjects-viewer > - > --> > > <listener> > > <listener-class>org.apache.isis.core.webapp.IsisWebAppBootstrapper</listener-class> > </listener> > > <!-- authenticate user, set up an Isis session --> > <filter> > <filter-name>IsisSessionFilter</filter-name> > <filter-class>org.apache.isis.core.webapp.IsisSessionFilter</filter-class> > <!-- authentication required for REST --> > <init-param> > <param-name>authenticationSessionStrategy</param-name> > > <param-value>org.apache.isis.viewer.restfulobjects.server.authentication.AuthenticationSessionStrategyTrusted</param-value> > </init-param> > <init-param> > <!-- what to do if no session was found; we indicate to issue > a 401 basic authentication challenge --> > <param-name>whenNoSession</param-name> > <param-value>unauthorized</param-value> > </init-param> > </filter> > <filter-mapping> > <filter-name>IsisSessionFilter</filter-name> > <url-pattern>/*</url-pattern> > </filter-mapping>/ > > > I expect you are fine and thanks so much. > > Best wishes, Nacho. > > -- > Ignacio Cánovas Rejón > Tel. 902 900 231 > Fax 96 353 19 09 > [email protected] > www.gesconsultor.com > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. > 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este > mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso > que los tuvieran eliminarlos. > > > > --- > Este mensaje no contiene virus ni malware porque la protección de avast! > Antivirus está activa. > http://www.avast.com >
