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
>

Reply via email to