You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Nacho Cánovas Rejón <n....@gesconsultor.com> on 2015/05/14 17:22:31 UTC
Session already open and context not configured for autoclose
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
n.canovas@gesconsultor.com
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
Re: Session already open and context not configured for autoclose
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
Hi Dan.
Thanks to look into this thread.
I'll tell you about how is working when I test it some days on our code.
Cheers.
El 09/07/2015 a las 18:47, GESCONSULTOR escribió:
> Many thanks, Dan.
>
> We will try it.
>
> Cheers,
>
> Oscar
>
>> El 9/7/2015, a las 18:32, Dan Haywood <da...@haywood-associates.co.uk> 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 <n....@gesconsultor.com>
>> 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 <n....@gesconsultor.com>
>>>> 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
>>>>> n.canovas@gesconsultor.com
>>>>> 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
>>> n.canovas@gesconsultor.com
>>> 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
n.canovas@gesconsultor.com
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.
https://www.avast.com/antivirus
Re: Session already open and context not configured for autoclose
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Many thanks, Dan.
We will try it.
Cheers,
Oscar
> El 9/7/2015, a las 18:32, Dan Haywood <da...@haywood-associates.co.uk> 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 <n....@gesconsultor.com>
> 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 <n....@gesconsultor.com>
>>> 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
>>>> n.canovas@gesconsultor.com
>>>> 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
>> n.canovas@gesconsultor.com
>> 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
>>
Re: Session already open and context not configured for autoclose
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <n....@gesconsultor.com>
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 <n....@gesconsultor.com>
>> 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
>>> n.canovas@gesconsultor.com
>>> 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
> n.canovas@gesconsultor.com
> 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
>
Re: Session already open and context not configured for autoclose
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
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 <n....@gesconsultor.com>
> 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
>> n.canovas@gesconsultor.com
>> 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
n.canovas@gesconsultor.com
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
Re: Session already open and context not configured for autoclose
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <n....@gesconsultor.com>
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
> n.canovas@gesconsultor.com
> 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
>