| InterruptedException on session-close [message #106297] |
Thu, 25 September 2008 12:14  |
 Stefan Hansel
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
We found a situation, where an InterruptedException is written on the
console on session-close.
Before opening a bug I wanted to discuss it, as I'm not sure how serious
this could be.
Here is the situation.
1) You need Tomcat 5.5 (didn't test behaviour in other servers)
2) You need a PhaseListener which accesses the current Session-Object
(RWT.getRequest.getSession())
3) I suppose you need to manually set the SessionTimeOut to something
short (at least this helps to reproduce the problem quite easily) in some
ActionListener. ( getSession().setMaxInactiveInterval(1) )
The InterruptedException will come up, if the session times out, while RWT
is still processes the event-queue (say our ActionListener).
(This can be easily reproduced, when just setting the breakpoint on the
'setMaxInactiveInterval'-call and waiting for one second)
The stacktrace then might look like this:
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1095)
at java.lang.Thread.join(Thread.java:1148)
at
org.eclipse.rwt.internal.lifecycle.UIThread.terminateThread( UIThread.java:54)
at
org.eclipse.rwt.internal.lifecycle.UIThread.interceptShutdow n(UIThread.java:86)
at
org.eclipse.rwt.internal.service.SessionStoreImpl.valueUnbou nd(SessionStoreImpl.java:142)
at
org.apache.catalina.session.StandardSession.removeAttributeI nternal(StandardSession.java:1630)
at
org.apache.catalina.session.StandardSession.expire(StandardS ession.java:749)
at
org.apache.catalina.session.StandardSession.isValid(Standard Session.java:581)
at org.apache.catalina.connector.Request.doGetSession(Request.j ava:2190)
at org.apache.catalina.connector.Request.getSession(Request.jav a:2031)
at
org.apache.catalina.connector.RequestFacade.getSession(Reque stFacade.java:832)
at
org.springframework.web.context.request.ServletRequestAttrib utes. <init>(ServletRequestAttributes.java:76)
at
org.springframework.web.context.request.ServletWebRequest.<init >(ServletWebRequest.java:41)
at
de.tolina.common.rwt.spring.OpenPersistenceManagerInViewPhas eListener.afterPhase(OpenPersistenceManagerInViewPhaseListen er.java:74)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.afterPhaseEx ecution(RWTLifeCycle.java:381)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:214)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:117)
at java.lang.Thread.run(Thread.java:595)
As you can see we are in some PhaseListener
(OpenPersistenceManagerInViewPhaseListener.afterPhase), which accesses the
SessionObject (in this case this happens in the org.springframework-code).
After that we are in Tomcat Classes (org.apache.catalina), which seems to
realize that the session timed out - thus the RAP-SessionStoreImpl is
informed.
The SessionStoreImpl now wants to kill the UIThread - and then honourful
wants to wait that it really has died ;-) ...
Problem ist ... in this scenario we are currently on the UIThread
(remember - we started in a PhaseListener) so metaphorically speaking:
We try to kill ourselfs and want to wait until we are dead, to do the
housekeeping afterwards ;-) ... no wonder java complains ...
In a 'normal' session-timeout scenario SessionStoreImpl.valueUnbound is
called from some other server-thread like this:
(Daemon Thread [ContainerBackgroundProcessor[StandardEngine[Catalina]]] )
SessionStoreImpl.valueUnbound(HttpSessionBindingEvent) line: 141
StandardSession.removeAttributeInternal(String, boolean) line: 1630
I suggest, that the SessionStoreImpl should check if it currently is in
some UIThread(). If that's the case, it had to react in a different way
... how is the big question ?
Or do you see any other way ?
As a workaround one could set the 'maxInactiveInterval' to something
higher, so chances to run into this are lower.
|
|
|
| InterruptedException on session-close [message #107810 is a reply to message #106297] |
Thu, 02 October 2008 13:57  |
Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
I think you've got a valid point here. From my first impression I would
agree that we have to handle a session shutdown differently in case we
are running in the UIThread - weird situation, but totally valid. I
think we can add this to the following bugzilla entry, since the
UIThread was introduced in the context of Display#readAndDispatch:
219789: Finalize Display#readAndDispatch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219789
One solution could be to recognize that the session shutdown
(SessionStoreImpl#valueUnbound()) takes place in the UIThread and
directly call value unbound. After that we have to find a way to exit
the event loop to terminate the UIThread, e.g. by throwing
UIThreadTerminatedError. But we will have to have a deeper look if this
could work...
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: stefan.hansel@tolina.de [mailto:stefan.hansel@tolina.de]
Bereitgestellt: Donnerstag, 25. September 2008 14:14
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: InterruptedException on session-close
Betreff: InterruptedException on session-close
We found a situation, where an InterruptedException is written on the
console on session-close.
Before opening a bug I wanted to discuss it, as I'm not sure how serious
this could be.
Here is the situation.
1) You need Tomcat 5.5 (didn't test behaviour in other servers)
2) You need a PhaseListener which accesses the current Session-Object
(RWT.getRequest.getSession())
3) I suppose you need to manually set the SessionTimeOut to something
short (at least this helps to reproduce the problem quite easily) in
some
ActionListener. ( getSession().setMaxInactiveInterval(1) )
The InterruptedException will come up, if the session times out, while
RWT
is still processes the event-queue (say our ActionListener).
(This can be easily reproduced, when just setting the breakpoint on the
'setMaxInactiveInterval'-call and waiting for one second)
The stacktrace then might look like this:
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1095)
at java.lang.Thread.join(Thread.java:1148)
at
org.eclipse.rwt.internal.lifecycle.UIThread.terminateThread( UIThread.jav
a:54)
at
org.eclipse.rwt.internal.lifecycle.UIThread.interceptShutdow n(UIThread.j
ava:86)
at
org.eclipse.rwt.internal.service.SessionStoreImpl.valueUnbou nd(SessionSt
oreImpl.java:142)
at
org.apache.catalina.session.StandardSession.removeAttributeI nternal(Stan
dardSession.java:1630)
at
org.apache.catalina.session.StandardSession.expire(StandardS ession.java:
749)
at
org.apache.catalina.session.StandardSession.isValid(Standard Session.java
:581)
at org.apache.catalina.connector.Request.doGetSession(Request.j ava:2190)
at org.apache.catalina.connector.Request.getSession(Request.jav a:2031)
at
org.apache.catalina.connector.RequestFacade.getSession(Reque stFacade.jav
a:832)
at
org.springframework.web.context.request.ServletRequestAttrib utes. <init>(
ServletRequestAttributes.java:76)
at
org.springframework.web.context.request.ServletWebRequest.<init >(Servlet
WebRequest.java:41)
at
de.tolina.common.rwt.spring.OpenPersistenceManagerInViewPhas eListener.af
terPhase(OpenPersistenceManagerInViewPhaseListener.java:74)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.afterPhaseEx ecution(RWTL
ifeCycle.java:381)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLif
eCycle.java:214)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(R
WTLifeCycle.java:117)
at java.lang.Thread.run(Thread.java:595)
As you can see we are in some PhaseListener
(OpenPersistenceManagerInViewPhaseListener.afterPhase), which accesses
the
SessionObject (in this case this happens in the
org.springframework-code).
After that we are in Tomcat Classes (org.apache.catalina), which seems
to
realize that the session timed out - thus the RAP-SessionStoreImpl is
informed.
The SessionStoreImpl now wants to kill the UIThread - and then honourful
wants to wait that it really has died ;-) ...
Problem ist ... in this scenario we are currently on the UIThread
(remember - we started in a PhaseListener) so metaphorically speaking:
We try to kill ourselfs and want to wait until we are dead, to do the
housekeeping afterwards ;-) ... no wonder java complains ...
In a 'normal' session-timeout scenario SessionStoreImpl.valueUnbound is
called from some other server-thread like this:
(Daemon Thread [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
)
SessionStoreImpl.valueUnbound(HttpSessionBindingEvent) line: 141
StandardSession.removeAttributeInternal(String, boolean) line: 1630
I suggest, that the SessionStoreImpl should check if it currently is in
some UIThread(). If that's the case, it had to react in a different way
... how is the big question ?
Or do you see any other way ?
As a workaround one could set the 'maxInactiveInterval' to something
higher, so chances to run into this are lower.
|
|
|
Powered by
FUDForum. Page generated in 0.03129 seconds
] 
Search
Help
Register
Login
Home
