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 <[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
--
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.
https://www.avast.com/antivirus
