Many thanks, Dan. We will try it.
Cheers, Oscar > El 9/7/2015, a las 18:32, Dan Haywood <[email protected]> > escribió: > > Hi Nacho (and Oscar) > > just wanted to come back to you on this old thread. While I don't know > that I've exactly pinned down the issue, I have tidied up the code that's > there and remove the "fail fast" logic. time will tell if that ends up > being a good decision or not. > > If you want to inspect the changes, see [1] and [2] > > Thanks > Dan > > [1] https://issues.apache.org/jira/browse/ISIS-1169 > [2] > https://github.com/apache/isis/commit/edc4fa7648f73dea2c3be41de24b29ca76af9fe4 > > > On 18 May 2015 at 15:14, Nacho Cánovas Rejón <[email protected]> > wrote: > >> Hi Dan. >> >> Don't worry about it, thanks very much. >> >> I'm too busy right now to solve it and I will follow your instructions. >> >> I did some research before, and I have some information about your >> theories and options. >> >> First of all, I changed DeploymentType from SERVER to SERVER_EXPLORATION, >> and if I remember correctly, this changed SessionClosePolicy as well, but I >> had another error instead about transactions I think (sorry I did this >> three weeks later). >> >> So, seems like yoy write, that a session is opened, but this would be >> closed.... >> >> Then I did some "dirty path" to IssisSessionFilter to UNDEFINED.handle >> method. >> >> openSession(validSession); >> SESSION_IN_PROGRESS.setOn(request); >> >> try { >> chain.doFilter(request, response); >> } finally { >> UNDEFINED.setOn(request); >> closeSession(); >> } >> return; >> >> >> to >> >> try { >> this.openSession(validSession); >> SESSION_IN_PROGRESS.setOn(request); >> chain.doFilter(request, response); >> } finally { >> UNDEFINED.setOn(request); >> this.closeSession(); >> } >> >> With this modification I had same message, but only one time, because >> thread releases session and like I said, the inconsistency doesn't arrive >> too often and problem is remaining in this threat when isn't closed. >> >> I don't know if this would help, but I'll tell you about my progress. >> >> Cheers. >> >> >>> El 16/05/2015 a las 14:08, Dan Haywood escribió: >>> >>> 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 >> >> -- >> 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 >>
