Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 12:44 Go to next message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
<font size=2 face="sans-serif">Hi there, </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Unfortunately we cannot reproduce it
locally.</font>
<br>
<br><font size=2 face="sans-serif">In the logs we found one exception which
might be the cause of that: </font>
<br><font size=2 face="sans-serif">----------</font>
<br><font size=2 face="sans-serif">Exception in thread &quot;UIThread [4F59A62615A5A8430B03331F1995B74C]&quot;
java.lang.IllegalStateException: The context has been disposed.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.ServiceContext.checkState(S erviceContext.java:154) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.ServiceContext.getRequest(S erviceContext.java:82) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.ContextProvider.getRequest( ContextProvider.java:129) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:148) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.setShutdownA dapter(RWTLifeCycle.java:350) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.access$0(RWT LifeCycle.java:347) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:133) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
java.lang.Thread.run(Unknown Source)</font>
<br><font size=2 face="sans-serif">----------</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">-------------</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp;</font><font size=2 color=#820040 face="Courier New"><b>private</b></font><font size=2 face="Courier New">
</font><font size=2 color=#820040 face="Courier New"><b>final</b></font><font size=2 face="Courier New">
</font><font size=2 color=#820040 face="Courier New"><b>class</b></font><font size=2 face="Courier New">
UIThreadController </font><font size=2 color=#820040 face="Courier New"><b>implements</b></font><font size=2 face="Courier New">
Runnable { &nbsp;</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp;</font><font size=2 color=#820040 face="Courier New"><b>public</b></font><font size=2 face="Courier New">
</font><font size=2 color=#820040 face="Courier New"><b>void</b></font><font size=2 face="Courier New">
run() {</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;IUIThreadHolder
uiThread = ( IUIThreadHolder )Thread.currentThread();</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=2 color=#820040 face="Courier New"><b>try</b></font><font size=2 face="Courier New">
{</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[...]</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}
</font><font size=2 color=#820040 face="Courier New"><b>catch</b></font><font size=2 face="Courier New">(
</font><font size=2 color=#820040 face="Courier New"><b>final</b></font><font size=2 face="Courier New">
Throwable thr ) {</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=2 color=#3f8080 face="Courier New"><b>// </b></font><font size=2 color=#71b2cf face="Courier New"><b>TODO</b></font><font size=2 color=#3f8080 face="Courier New"><b>
[rh] preliminary fix for </b></font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=2 color=#3f8080 face="Courier New"><b>// &nbsp;
&nbsp; &nbsp;</b></font><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=232289"><font size=2 color=#3f8080 face="Courier New"><b>https://bugs.eclipse.org/bugs/show_bug.cgi?id=232289</b></font></a>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=2 color=#3f8080 face="Courier New"><b>// &nbsp;
&nbsp; &nbsp;For a decent solution, see these ideas</b></font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=2 color=#3f8080 face="Courier New"><b>// &nbsp;
&nbsp; &nbsp;</b></font><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=219465"><font size=2 color=#3f8080 face="Courier New"><b>https://bugs.eclipse.org/bugs/show_bug.cgi?id=219465</b></font></a>
<br><font size=2 face="Courier New">line 133: &nbsp; setShutdownAdapter(
</font><font size=2 color=#820040 face="Courier New"><b>null</b></font><font size=2 face="Courier New">
); &nbsp; // line 133</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;IServiceStateInfo stateInfo = ContextProvider.getStateInfo();</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;stateInfo.setAttribute( UI_THREAD_THROWABLE, thr );</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">-------------</font>
<br>
<br><font size=2 face="sans-serif">If I see correctly the RWTLifeCycleClass
was changed in 1.3.M3 , at least it doesn't call 'setShutdownAdapater()'
anymore.</font>
<br>
<br><font size=2 face="sans-serif">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 ? </font>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">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 !</font>
<br>
<br><font size=2 face="sans-serif">Kind Regards</font>
<br><font size=2 face="sans-serif">Stefan </font>
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 13:00 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
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 14:27 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
<font size=2 face="sans-serif">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).</font>
<br><font size=2 face="sans-serif">Using a ThreadDump I see that there
is one Thread holding a lock which prevents any later HTTP-Request to be
answered: </font>
<br>
<br>
<br><font size=2 face="sans-serif">--- waiting thread holding a lock and
waiting --------</font>
<br><font size=2 face="sans-serif">&quot;http-8080-15&quot; daemon prio=6
tid=0x0b954000 nid=0x1990 in Object.wait() [0x0e7ee000]</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;java.lang.Thread.State:
WAITING (on object monitor)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
java.lang.Object.wait(Native Method)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; -
waiting on &lt;0x0486fd90&gt; (a org.eclipse.rwt.internal.lifecycle.UIThread)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
java.lang.Object.wait(Object.java:485)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.UIThread.switchThread(UIT hread.java:50) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; -
locked &lt;0x0486fd90&gt; (a org.eclipse.rwt.internal.lifecycle.UIThread)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.executeUIThr ead(RWTLifeCycle.java:268) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.execute(RWTL ifeCycle.java:157) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler$1.r un(LifeCycleServiceHandler.java:61) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.int ernalService(LifeCycleServiceHandler.java:193) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.acc ess$1(LifeCycleServiceHandler.java:185) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler$Lif eCycleServiceHandlerSync.doService(LifeCycleServiceHandler.j ava:150) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.serviceInternal(RWTLifeCycleServiceHandlerSync.java:48 ) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.service(RWTLifeCycleServiceHandlerSync.java:36) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; -
locked &lt;0x048720a0&gt; (a org.eclipse.rwt.internal.service.SessionStoreImpl)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.ser vice(LifeCycleServiceHandler.java:157) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:101) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegat e.java:45) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
javax.servlet.http.HttpServlet.service(HttpServlet.java:690) </font>
<br>
<br><font size=2 face="sans-serif">---- next blocked HTTP-request ---------</font>
<br><font size=2 face="sans-serif">&quot;http-8080-20&quot; daemon prio=6
tid=0x0be02000 nid=0x1d40 waiting for monitor entry [0x0ecef000]</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;java.lang.Thread.State:
BLOCKED (on object monitor)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycleServiceHandle rSync.service(RWTLifeCycleServiceHandlerSync.java:35) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; -
waiting to lock &lt;0x048720a0&gt; (a org.eclipse.rwt.internal.service.SessionStoreImpl)</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.LifeCycleServiceHandler.ser vice(LifeCycleServiceHandler.java:157) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.service.ServiceManager$HandlerDispa tcher.service(ServiceManager.java:101) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.engine.RWTDelegate.doPost(RWTDelega te.java:63) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
org.eclipse.rwt.internal.engine.RWTDelegate.doGet(RWTDelegat e.java:45) </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; at
javax.servlet.http.HttpServlet.service(HttpServlet.java:690) </font>
<br>
<br>
<br><font size=2 face="sans-serif">This brings down the whole RAP 1.2.1
app, as noone seems to wake the first Thread anymore. </font>
<br><font size=2 face="sans-serif">Is this a known bug of RAP 1.2.1 possible
fixed in 1.2.2 ?</font>
<br>
<br><font size=2 face="sans-serif">Any idea to prevent getting into such
a situation ?</font>
<br>
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 22:04 Go to previous messageGo to next message
Rüdiger Herrmann is currently offline Rüdiger HerrmannFriend
Messages: 581
Registered: July 2009
Senior Member
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 07:18 Go to previous message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
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:
  


Current Time: Thu Mar 28 21:06:47 GMT 2024

Powered by FUDForum. Page generated in 0.05081 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top