|
|
| Re: UI-thread sleeping despite Runnables [message #522462 is a reply to message #522446] |
Mon, 22 March 2010 17:32   |
 Ulrich Kreher
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hi Rüdiger,
I am not sure whether this is the same bug, we do not have a modal
context at all but a lot of calls to Display.syncExec(Runnable) that are
caused by updates on the server side our RAP-application is a client of.
That is, we have a lot of updates for the callback request and very
few direct service requests from the browser side.
Currently I am investigating our problem since it is very critical for
our application. I found the waitForUIThread-flag in the
UICallBackManager being true (see attachment NonUIThread-LocVars.txt of
my last post). This will block the callback request even if there are
runnables – runnables.isEmpty() is not checked at all in
mustBlockCallBackRequest(). However, as I understand it right now, this
should not happen at all.
As soon as I can provide more details on the strange value of the flag,
I will file a new bug.
Thanks for your help,
Ulrich
Rüdiger Herrmann schrieb:
> Ulrich,
>
> thanks for the detailed report. You probably ran into this bug:
> 280187: ModalContext removes UICallback too early
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=280187
> However, it would be much appreciated if you could file another
> bugzilla, as the one mentioned isn't very focused.
> We will address this issue towards the end of the 1.3 development cycle.
>
> TIA
> Rüdiger
|
|
|
|
| Re: UI-thread sleeping despite Runnables [message #530042 is a reply to message #524102] |
Wed, 28 April 2010 09:33 |
Rüdiger Herrmann
Messages: 581
Registered: July 2009 |
Senior Member |
|
|
Ulrich,
we finally found the time to address bugs related to (a)syncExec and the
UICallback.
We think the problem that you describe is solved with these changes.
Please also see the comment on bug 307048
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=307048> (Deadlock due to
UI-thread sleeping despite runnables).
Regards
Rüdiger
--
Rüdiger Herrmann
http://eclipsesource.com
On 30.03.2010 19:10, Ulrich Kreher wrote:
> Since the occured deadlock renders our application unusable (it can
> occur several times in one hour), we investigated our problem some more:
>
> The patch I filed for the waitForUIThread-flag
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=307048) does not solve
> the deadlock. Therefore we logged the UI-Thread starting and ending, the
> callback request entering and leaving (all in the UICallBackManager) as
> well as all service requests arriving (in ServiceManager) – see the
> attached ThreadLogs.txt. Additionally we used Wireshark to log the
> HTTP-traffic expecting some lost messages.
> Changing the Eclipse-View in our RAP-application (using IE8) triggered a
> timed update and the complete UI froze immediately after changing the
> view. We suspended the JVM and created the stacktraces. They indicate
> that we have the very same deadlock again, that is the callback thread
> waiting for the UI-Thread (see CallbackThread-Stack.txt), having
> runnables (this time a TimerRunnable, see CallbackThread-LocVars.txt)
> and the UI-Thread waiting for a service request (see UIThread.txt).
>
> We found another thread having an interesting stack trace: A service
> request was doing some POST-retrieval right before “servicing” (see
> POSTThread-Stack.txt). Probably this is the thread to wake up the
> UI-Thread but unfortunately its stuck trying to read the POST-message –
> this should be the last message Wireshark logged (see HTTP-Traffic.txt).
>
> We would really appreciate someone having deeper RAP-knowledge to tell
> us, whether this POST-retrieval is intended and/or could be the cause
> for the deadlock. This may help in narrowing down this bug (assumed it
> is one).
>
> Many thanks,
>
> Ulrich
|
|
|
Powered by
FUDForum. Page generated in 0.03899 seconds
] 
Search
Help
Register
Login
Home
