Eclipse Community Forums: Remote Application Platform (RAP) » strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1

Home » Eclipse Projects » Remote Application Platform (RAP) » strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1

strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1 [message #535731]

Tue, 25 May 2010 08:44

Eclipse User

Hi there, 
 
 We have one customer who claims that
our RAP.1.2.1-app crashes from time to time (no user can connect, all just
see a white page) and only a restart of Tomcat helps.
 Unfortunately we cannot reproduce it
locally.
 
 In the logs we found one exception which
might be the cause of that: 
 ----------
 Exception in thread "UIThread [4F59A62615A5A8430B03331F1995B74C]"
java.lang.IllegalStateException: The context has been disposed.
         at
org.eclipse.rwt.internal.service.ServiceContext.checkState(S erviceContext.java:154) 
         at
org.eclipse.rwt.internal.service.ServiceContext.getRequest(S erviceContext.java:82) 
         at
org.eclipse.rwt.internal.service.ContextProvider.getRequest( ContextProvider.java:129) 
         at
org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:148) 
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.setShutdownA dapter(RWTLifeCycle.java:350) 
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.access$0(RWT LifeCycle.java:347) 
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:133) 
         at
java.lang.Thread.run(Unknown Source)
 ----------
 
 As you can see its within RAP and if
I look at the RWTLifeCycleClass of 1.2.1 it seems that the original 'Throwable
thr' was swallowed, so we cannot get the Root-Cause.
 -------------
      private
final
class
UIThreadController implements
Runnable {  
        public
void
run() {
          IUIThreadHolder
uiThread = ( IUIThreadHolder )Thread.currentThread();
          try
{
          
         [...]
          }
catch(
final
Throwable thr ) {
          
 // TODO
[rh] preliminary fix for 
          
 //  
   <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=232289">https://bugs.eclipse.org/bugs/show_bug.cgi?id=232289</a>
          
 //  
   For a decent solution, see these ideas
          
 //  
   <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=219465">https://bugs.eclipse.org/bugs/show_bug.cgi?id=219465</a>
 line 133:   setShutdownAdapter(
null
);   // line 133
          
 IServiceStateInfo stateInfo = ContextProvider.getStateInfo();
          
 stateInfo.setAttribute( UI_THREAD_THROWABLE, thr );
          }
        }
      }
 -------------
 
 If I see correctly the RWTLifeCycleClass
was changed in 1.3.M3 , at least it doesn't call 'setShutdownAdapater()'
anymore.
 
 Could you give us any hints from your
experience what could cause the original problem in RAP 1.2.1 and how we
could circumvent it ? 
 We are a bit reluctant to just put RAP
1.3.M3 or later into production, without testing it thoroughly (and not
even knowing if it would fix the problem).
 
 So any idea making us able to reproduce
this error or searching for strange RAP usage in our own code would help
us very much !
 
 Kind Regards
 Stefan

Re: strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1 [message #535734 is a reply to message #535731]

Tue, 25 May 2010 09:00

Eclipse User

I just realized that my NNTP-Reader produces HTML (which the Web-Forum doesn't render), so here the message again in plain text, if anyone can't read it easily.

Hi there,

We have one customer who claims that our RAP.1.2.1-app crashes from time to time (no user can connect, all just see a white page) and only a restart of Tomcat helps.
Unfortunately we cannot reproduce it locally.

In the logs we found one exception which might be the cause of that:
----------
Exception in thread "UIThread [4F59A62615A5A8430B03331F1995B74C]" java.lang.IllegalStateException: The context has been disposed.
at org.eclipse.rwt.internal.service.ServiceContext.checkState(S erviceContext.java:154)
at org.eclipse.rwt.internal.service.ServiceContext.getRequest(S erviceContext.java:82)
at org.eclipse.rwt.internal.service.ContextProvider.getRequest( ContextProvider.java:129)
at org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:148)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.setShutdownA dapter(RWTLifeCycle.java:350)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.access$0(RWT LifeCycle.java:347)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:133)
at java.lang.Thread.run(Unknown Source)
----------

As you can see its within RAP and if I look at the RWTLifeCycleClass of 1.2.1 it seems that the original 'Throwable thr' was swallowed, so we cannot get the Root-Cause.
-------------
private final class UIThreadController implements Runnable {
public void run() {
IUIThreadHolder uiThread = ( IUIThreadHolder )Thread.currentThread();
try {
[...]
} catch( final Throwable thr ) {
// TODO [rh] preliminary fix for
// https://bugs.eclipse.org/bugs/show_bug.cgi?id=232289
// For a decent solution, see these ideas
// https://bugs.eclipse.org/bugs/show_bug.cgi?id=219465
line 133: setShutdownAdapter( null ); // line 133
IServiceStateInfo stateInfo = ContextProvider.getStateInfo();
stateInfo.setAttribute( UI_THREAD_THROWABLE, thr );
}
}
}
-------------

If I see correctly the RWTLifeCycleClass was changed in 1.3.M3 , at least it doesn't call 'setShutdownAdapater()' anymore.

Could you give us any hints from your experience what could cause the original problem in RAP 1.2.1 and how we could circumvent it ?
We are a bit reluctant to just put RAP 1.3.M3 or later into production, without testing it thoroughly (and not even knowing if it would fix the problem).

So any idea making us able to reproduce this error or searching for strange RAP usage in our own code would help us very much !

Kind Regards
Stefan

Re: strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1 [message #535975 is a reply to message #535734]

Wed, 26 May 2010 10:27

Eclipse User

I was finally able to reproduce the problem,
by putting some load on the RAP-Application with JMeter (and going near
to a situation, where an OutOfMemory would happen somewhere).
 Using a ThreadDump I see that there
is one Thread holding a lock which prevents any later HTTP-Request to be
answered: 
 
 
 --- waiting thread holding a lock and
waiting --------
 "http-8080-15" daemon prio=6
tid=0x0b954000 nid=0x1990 in Object.wait() [0x0e7ee000]
    java.lang.Thread.State:
WAITING (on object monitor)
         at
java.lang.Object.wait(Native Method)
         -
waiting on <0x0486fd90> (a org.eclipse.rwt.internal.lifecycle.UIThread)
         at
java.lang.Object.wait(Object.java:485)
         at
org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIT hread.java:50) 
         -
locked <0x0486fd90> (a org.eclipse.rwt.internal.lifecycle.UIThread)
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.executeUIThr ead(RWTLifeCycle.java:268) 
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.execute(RWTL ifeCycle.java:157) 
         at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler$1.r un(LifeCycleServiceHandler.java:61) 
         at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.int ernalService(LifeCycleServiceHandler.java:193) 
         at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.acc ess$1(LifeCycleServiceHandler.java:185) 
         at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler$Lif eCycleServiceHandlerSync.doService(LifeCycleServiceHandler.j ava:150) 
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.serviceInternal(RWTLifeCycleServiceHandlerSync.java:48 ) 
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.service(RWTLifeCycleServiceHandlerSync.java:36) 
         -
locked <0x048720a0> (a org.eclipse.rwt.internal.service.SessionStoreImpl)
         at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.ser vice(LifeCycleServiceHandler.java:157) 
         at
org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:101) 
         at
org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63) 
         at
org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegat e.java:45) 
         at
javax.servlet.http.HttpServlet.service(HttpServlet.java:690) 
 
 ---- next blocked HTTP-request ---------
 "http-8080-20" daemon prio=6
tid=0x0be02000 nid=0x1d40 waiting for monitor entry [0x0ecef000]
    java.lang.Thread.State:
BLOCKED (on object monitor)
         at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.service(RWTLifeCycleServiceHandlerSync.java:35) 
         -
waiting to lock <0x048720a0> (a org.eclipse.rwt.internal.service.SessionStoreImpl)
         at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.ser vice(LifeCycleServiceHandler.java:157) 
         at
org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:101) 
         at
org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63) 
         at
org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegat e.java:45) 
         at
javax.servlet.http.HttpServlet.service(HttpServlet.java:690) 
 
 
 This brings down the whole RAP 1.2.1
app, as noone seems to wake the first Thread anymore. 
 Is this a known bug of RAP 1.2.1 possible
fixed in 1.2.2 ?
 
 Any idea to prevent getting into such
a situation ?

Re: strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1 [message #536082 is a reply to message #535975]

Wed, 26 May 2010 18:04

Eclipse User

Hi Stefan,

glad to hear that you could reproduce the problem. The only bug that
even remotely comes close to what you describe is this one:
Rap UI Locks up when a runnable is running, and a page reload happens
https://bugs.eclipse.org/bugs/show_bug.cgi?id=284202
It was fixed in 1.2.2. However, I don't belive that this is the source
of your problem.
During the 1.3 development cycle some more bugs were fixed that could be
related to what you describe. With your JMeter setup in place, did you
try to run the tests with 1.3 to see if the situation changes?

HTH
Rüdiger

On 26.05.2010 16:27, stefan.hansel@tolina.de wrote:
> I was finally able to reproduce the problem, by putting some load on the
> RAP-Application with JMeter (and going near to a situation, where an
> OutOfMemory would happen somewhere).
> Using a ThreadDump I see that there is one Thread holding a lock which
> prevents any later HTTP-Request to be answered:
>
>
> --- waiting thread holding a lock and waiting --------
> "http-8080-15" daemon prio=6 tid=0x0b954000 nid=0x1990 in Object.wait()
> [0x0e7ee000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0486fd90> (a org.eclipse.rwt.internal.lifecycle.UIThread)
> at java.lang.Object.wait(Object.java:485)
> at
> org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIT hread.java:50)
> - locked <0x0486fd90> (a org.eclipse.rwt.internal.lifecycle.UIThread)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.executeUIThr ead(RWTLifeCycle.java:268)
>
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.execute(RWTL ifeCycle.java:157)
>
> at
> org.eclipse.rwt.internal.service.LifeCycleServiceHandler$1.r un(LifeCycleServiceHandler.java:61)
>
> at
> org.eclipse.rwt.internal.service.LifeCycleServiceHandler.int ernalService(LifeCycleServiceHandler.java:193)
>
> at
> org.eclipse.rwt.internal.service.LifeCycleServiceHandler.acc ess$1(LifeCycleServiceHandler.java:185)
>
> at
> org.eclipse.rwt.internal.service.LifeCycleServiceHandler$Lif eCycleServiceHandlerSync.doService(LifeCycleServiceHandler.j ava:150)
>
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.serviceInternal(RWTLifeCycleServiceHandlerSync.java:48 )
>
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.service(RWTLifeCycleServiceHandlerSync.java:36)
>
> - locked <0x048720a0> (a org.eclipse.rwt.internal.service.SessionStoreImpl)
> at
> org.eclipse.rwt.internal.service.LifeCycleServiceHandler.ser vice(LifeCycleServiceHandler.java:157)
>
> at
> org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:101)
>
> at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
> at org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegat e.java:45)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>
> ---- next blocked HTTP-request ---------
> "http-8080-20" daemon prio=6 tid=0x0be02000 nid=0x1d40 waiting for
> monitor entry [0x0ecef000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.service(RWTLifeCycleServiceHandlerSync.java:35)
>
> - waiting to lock <0x048720a0> (a
> org.eclipse.rwt.internal.service.SessionStoreImpl)
> at
> org.eclipse.rwt.internal.service.LifeCycleServiceHandler.ser vice(LifeCycleServiceHandler.java:157)
>
> at
> org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:101)
>
> at org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63)
> at org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegat e.java:45)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>
>
> This brings down the whole RAP 1.2.1 app, as noone seems to wake the
> first Thread anymore.
> Is this a known bug of RAP 1.2.1 possible fixed in 1.2.2 ?
>
> Any idea to prevent getting into such a situation ?

--
Rüdiger Herrmann
http://eclipsesource.com

Re: strange 'context has been disposed' problems in RWTLifeCycle-class in rap 1.2.1 [message #536120 is a reply to message #536082]

Thu, 27 May 2010 03:18

Eclipse User

Am 27.05.2010 00:04, schrieb Rüdiger Herrmann:
> Hi Stefan,
>
> glad to hear that you could reproduce the problem. The only bug that
> even remotely comes close to what you describe is this one:
> Rap UI Locks up when a runnable is running, and a page reload happens
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=284202
> It was fixed in 1.2.2. However, I don't belive that this is the source
> of your problem.

Rüdiger - thanks for this suggestion.
I realize, that indeed this bug related to the one you mentioned might
be our problem:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=258102

Typically our progress-bars are not seen very long, but through the
JMeter-Tests and Garbage Collection Cycles in the end I saw some longer
progressbars (and luckily clicked around and reloaded the page while
JMeter and the progressbar was running).

I now get the same exception as in post #1 and am also running in the
Deadlock.
Running RAP1.3M3 (this is the only other version we currently allow in
production) I can't reproduce it anymore so this is good enough to
provide a new version to our customer in the hope his problems vanish.

Regards
Stefan

Previous Topic:	How to get the init params of the bridge servlet?
Next Topic:	change business design

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 04 20:59:00 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter