Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Severe problem with BlockedJobsDialog, from Lock
| Severe problem with BlockedJobsDialog, from Lock [message #40321] |
Thu, 20 July 2006 22:38  |
 Harley Nelson
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
I posted a similar question on the GMF group, and have not received an
answer in a week or so.
I'm having a severe problem with the BlockedJobsDialog, i.e. "User
Operation is Waiting", popping up every couple of seconds. This is making
my application completely unusable. The application is a basic GMF
editor, with the slight difference that transient model attributes are
being modified constantly by database callbacks.
If I just have an EMF tree showing, the popups do not occur. But if GMF
is running (even with no content, just a blank diagram), any changes to
the EMF model through transactions cause a constant state of the dialog
box popping up and down.
Is there any way to disable or tune the BlockedJobsDialog, or keep the
Lock/JobManager from launching it? Or any other solution to tune it so it
doesn't constantly pop up?
Thanks,
Harley.
|
|
|
| Re: Severe problem with BlockedJobsDialog, from Lock [message #40386 is a reply to message #40321] |
Fri, 21 July 2006 12:03  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Harley,
Sorry, I regularly scan the GMF newsgroup for EMFT-related questions, but I
guess I missed yours.
This dialog will only pop up when two factors concur:
- the UI thread is trying to start a transaction
- another thread currently has an active transaction
It sounds like, in your case, the UI thread and some thread are both
repeatedly running short transactions, and sometimes they try to overlap.
The dialog has an 800 millis delay (hard-coded in Eclipse platform), so
it's a little surprising that it occurs so frequently.
Can the transactions that are currently running on the UI thread be done on
a background thread, instead? If these transactions need to run snippets
on the UI thread (which snippets need to read the EMF model), then they can
can be executed in privileged runnables in a Display.syncExec() call. The
sequence would be like:
1. Background thread starts transaction.
2. Background thread reads model stuff.
3. Background thread creates a Runnable to do stuff on the UI
thread, and "blesses" it via
TransactionalEditingDomain.createPrivilegedRunnable(Runnable ).
4. Background thread Display.syncExec()s the privileged runnable.
4.1 UI thread executes the privileged runnable, reading the
model if necessary. The runnable gives it access to the
editing domain transaction owned by the background thread,
so that it does not have to block waiting for access.
5. Background thread resumes, reads model stuff.
6. Background thread closes transaction.
There isn't currently any way to tune the appearance of the dialog, and it
would take some fancy new API to make this work, as it would sneak a
back-door UI dependency into the transaction core (the JobManager API does
not have the tuning facilities that you're looking for).
HTH,
Christian
Harley wrote:
> I posted a similar question on the GMF group, and have not received an
> answer in a week or so.
>
> I'm having a severe problem with the BlockedJobsDialog, i.e. "User
> Operation is Waiting", popping up every couple of seconds. This is making
> my application completely unusable. The application is a basic GMF
> editor, with the slight difference that transient model attributes are
> being modified constantly by database callbacks.
>
> If I just have an EMF tree showing, the popups do not occur. But if GMF
> is running (even with no content, just a blank diagram), any changes to
> the EMF model through transactions cause a constant state of the dialog
> box popping up and down.
>
> Is there any way to disable or tune the BlockedJobsDialog, or keep the
> Lock/JobManager from launching it? Or any other solution to tune it so it
> doesn't constantly pop up?
>
> Thanks,
>
> Harley.
|
|
| |
| Re: Severe problem with BlockedJobsDialog, from Lock [message #40478 is a reply to message #40448] |
Fri, 21 July 2006 15:43 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Harley,
Yes, that would be very bad, indeed. If you change the isConflicting()
implementation to return false, then you will violate the JobManager's
requirement that scheduling rules conflict with themselves (this is
enforced by the JobManager.validateRule method).
If you have already applied this change, then you should be getting
IllegalArgumentExceptions from the JobManager on attempts to acquire the
lock. If you make any other changes to the isConflicting() implementation,
then the UI thread will run ahead of the acquisition of the lock and assume
that it has the lock before it does. i.e., it will not wait for the lock
but will just proceed to create a transaction and probably corrupt some
other thread's transaction.
Cheers,
Christian
Harley wrote:
> Thanks for the reply. I'll work on refactoring things to do what you
> suggested. I think the reason I'm getting popups so often isn't because
> of the length of my transactions, but because of quantity. I have
> literally hundreds of transient attributes that are being constantly
> updated by a database, so the chances that something is active when the
> 800 ms window passes is pretty high.
>
> As an attempt at a fix, I modified Lock.AquireRule.isConflicting() to
> return false. This gets rid of the popups. If I want to do a release of
> my program with this in place, will it have any nasty side effects?
|
|
| |
| Re: Severe problem with BlockedJobsDialog (freaky GMF thing) [message #40753 is a reply to message #40508] |
Mon, 24 July 2006 13:26 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Harley,
Hmmm ... I don't think I understand what this isHostResolvable() method is
trying to do. Presumably, if the EditPart that owns this
PopupBarEditPolicy is visible on the screen, then it has already resolved
its view's semantic element in order to display it. If it didn't succeed
in resolving the element, then presumably it is unresolvable, so further
attempts are futile.
I think you will need to follow up on the GMF newsgroup to find out why this
code is necessary, and what you may be able to do to work around it.
Cheers,
Christian
Harley wrote:
> I think the transaction on the UI thread may be coming from GMF itself. I
> noticed something a little strange. "Mouse move" in GMF's
> PopupBarEditPolicy calls "isHostResolvable", which looks sort of like
> this:
>
> ---------
> private boolean isHostResolvable() {
> final View view = (View) getHost().getModel();
> if (view.getElement() != null) {
> Boolean retval;
> try {
> retval = (Boolean) ((IGraphicalEditPart) getHost())
> .getEditingDomain().runExclusive(
> new RunnableWithResult.Impl() {
>
> public void run() {
> setResult(ViewUtil.resolveSemanticElement(view) != null ? Boolean.TRUE
> : Boolean.FALSE);
> }
> });
> return retval.booleanValue();
> } catch (InterruptedException e) {
> ..
> ----------
>
> Which causes a stack that looks like this:
>
> org.eclipse.emf.transaction.util.Lock.uiSafeAcquire(Lock.jav a:352)
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.acquire(TransactionalEditingDomainImpl.java:503)
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.activate(TransactionalEditingDomainImpl.java:437)
>
org.eclipse.emf.transaction.impl.TransactionImpl.start(Trans actionImpl.java:154)
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.startTransaction(TransactionalEditingDomainImpl.java:353 )
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.runExclusive(TransactionalEditingDomainImpl.java:251)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssis tantEditPolicy.isHostResolvable(DiagramAssistantEditPolicy.j ava:261)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssis tantEditPolicy.shouldShowDiagramAssistant(DiagramAssistantEd itPolicy.java:209)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEdit Policy.shouldShowDiagramAssistant(PopupBarEditPolicy.java:64 6)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssis tantEditPolicy.showDiagramAssistantAfterDelay(DiagramAssista ntEditPolicy.java:314)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEdit Policy.showDiagramAssistantAfterDelay(PopupBarEditPolicy.jav a:998)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEdit Policy.mouseMoved(PopupBarEditPolicy.java:435)
>
> -----------
>
> I think this may be a big part of the problem I'm having. Any suggestions
> on how to work around this?
>
> Thanks,
>
> Harley.
|
|
|
| Re: Severe problem with BlockedJobsDialog, from Lock [message #582819 is a reply to message #40321] |
Fri, 21 July 2006 12:03 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Harley,
Sorry, I regularly scan the GMF newsgroup for EMFT-related questions, but I
guess I missed yours.
This dialog will only pop up when two factors concur:
- the UI thread is trying to start a transaction
- another thread currently has an active transaction
It sounds like, in your case, the UI thread and some thread are both
repeatedly running short transactions, and sometimes they try to overlap.
The dialog has an 800 millis delay (hard-coded in Eclipse platform), so
it's a little surprising that it occurs so frequently.
Can the transactions that are currently running on the UI thread be done on
a background thread, instead? If these transactions need to run snippets
on the UI thread (which snippets need to read the EMF model), then they can
can be executed in privileged runnables in a Display.syncExec() call. The
sequence would be like:
1. Background thread starts transaction.
2. Background thread reads model stuff.
3. Background thread creates a Runnable to do stuff on the UI
thread, and "blesses" it via
TransactionalEditingDomain.createPrivilegedRunnable(Runnable ).
4. Background thread Display.syncExec()s the privileged runnable.
4.1 UI thread executes the privileged runnable, reading the
model if necessary. The runnable gives it access to the
editing domain transaction owned by the background thread,
so that it does not have to block waiting for access.
5. Background thread resumes, reads model stuff.
6. Background thread closes transaction.
There isn't currently any way to tune the appearance of the dialog, and it
would take some fancy new API to make this work, as it would sneak a
back-door UI dependency into the transaction core (the JobManager API does
not have the tuning facilities that you're looking for).
HTH,
Christian
Harley wrote:
> I posted a similar question on the GMF group, and have not received an
> answer in a week or so.
>
> I'm having a severe problem with the BlockedJobsDialog, i.e. "User
> Operation is Waiting", popping up every couple of seconds. This is making
> my application completely unusable. The application is a basic GMF
> editor, with the slight difference that transient model attributes are
> being modified constantly by database callbacks.
>
> If I just have an EMF tree showing, the popups do not occur. But if GMF
> is running (even with no content, just a blank diagram), any changes to
> the EMF model through transactions cause a constant state of the dialog
> box popping up and down.
>
> Is there any way to disable or tune the BlockedJobsDialog, or keep the
> Lock/JobManager from launching it? Or any other solution to tune it so it
> doesn't constantly pop up?
>
> Thanks,
>
> Harley.
|
|
| |
| Re: Severe problem with BlockedJobsDialog, from Lock [message #582876 is a reply to message #40448] |
Fri, 21 July 2006 15:43 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Harley,
Yes, that would be very bad, indeed. If you change the isConflicting()
implementation to return false, then you will violate the JobManager's
requirement that scheduling rules conflict with themselves (this is
enforced by the JobManager.validateRule method).
If you have already applied this change, then you should be getting
IllegalArgumentExceptions from the JobManager on attempts to acquire the
lock. If you make any other changes to the isConflicting() implementation,
then the UI thread will run ahead of the acquisition of the lock and assume
that it has the lock before it does. i.e., it will not wait for the lock
but will just proceed to create a transaction and probably corrupt some
other thread's transaction.
Cheers,
Christian
Harley wrote:
> Thanks for the reply. I'll work on refactoring things to do what you
> suggested. I think the reason I'm getting popups so often isn't because
> of the length of my transactions, but because of quantity. I have
> literally hundreds of transient attributes that are being constantly
> updated by a database, so the chances that something is active when the
> 800 ms window passes is pretty high.
>
> As an attempt at a fix, I modified Lock.AquireRule.isConflicting() to
> return false. This gets rid of the popups. If I want to do a release of
> my program with this in place, will it have any nasty side effects?
|
|
| |
| Re: Severe problem with BlockedJobsDialog (freaky GMF thing) [message #583012 is a reply to message #40508] |
Mon, 24 July 2006 13:26 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Harley,
Hmmm ... I don't think I understand what this isHostResolvable() method is
trying to do. Presumably, if the EditPart that owns this
PopupBarEditPolicy is visible on the screen, then it has already resolved
its view's semantic element in order to display it. If it didn't succeed
in resolving the element, then presumably it is unresolvable, so further
attempts are futile.
I think you will need to follow up on the GMF newsgroup to find out why this
code is necessary, and what you may be able to do to work around it.
Cheers,
Christian
Harley wrote:
> I think the transaction on the UI thread may be coming from GMF itself. I
> noticed something a little strange. "Mouse move" in GMF's
> PopupBarEditPolicy calls "isHostResolvable", which looks sort of like
> this:
>
> ---------
> private boolean isHostResolvable() {
> final View view = (View) getHost().getModel();
> if (view.getElement() != null) {
> Boolean retval;
> try {
> retval = (Boolean) ((IGraphicalEditPart) getHost())
> .getEditingDomain().runExclusive(
> new RunnableWithResult.Impl() {
>
> public void run() {
> setResult(ViewUtil.resolveSemanticElement(view) != null ? Boolean.TRUE
> : Boolean.FALSE);
> }
> });
> return retval.booleanValue();
> } catch (InterruptedException e) {
> ..
> ----------
>
> Which causes a stack that looks like this:
>
> org.eclipse.emf.transaction.util.Lock.uiSafeAcquire(Lock.jav a:352)
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.acquire(TransactionalEditingDomainImpl.java:503)
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.activate(TransactionalEditingDomainImpl.java:437)
>
org.eclipse.emf.transaction.impl.TransactionImpl.start(Trans actionImpl.java:154)
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.startTransaction(TransactionalEditingDomainImpl.java:353 )
>
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.runExclusive(TransactionalEditingDomainImpl.java:251)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssis tantEditPolicy.isHostResolvable(DiagramAssistantEditPolicy.j ava:261)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssis tantEditPolicy.shouldShowDiagramAssistant(DiagramAssistantEd itPolicy.java:209)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEdit Policy.shouldShowDiagramAssistant(PopupBarEditPolicy.java:64 6)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssis tantEditPolicy.showDiagramAssistantAfterDelay(DiagramAssista ntEditPolicy.java:314)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEdit Policy.showDiagramAssistantAfterDelay(PopupBarEditPolicy.jav a:998)
>
org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEdit Policy.mouseMoved(PopupBarEditPolicy.java:435)
>
> -----------
>
> I think this may be a big part of the problem I'm having. Any suggestions
> on how to work around this?
>
> Thanks,
>
> Harley.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:25:36 GMT 2024
Powered by FUDForum. Page generated in 0.04328 seconds |
] 
Search
Help
Register
Login
Home
