Home » Eclipse Projects » Oomph » "Random" failures with multiple mwe2 launches depending on each other
|
| Re: "Random" failures with multiple mwe2 launches depending on each other [message #1714832 is a reply to message #1714804] |
Tue, 17 November 2015 06:36   |
 Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Stephan,
Is this a setup you can share (in its current state) that I might try to
reproduce the problem?
The latest problem looks strange. What -Doomph.redirection.* do yo
have in your eclipse.ini? Can you reproduce this problem in a runtime
IDE launch where you can inspect the URI involved? Normally it would be
the constant defined by
org.eclipse.oomph.setup.internal.core.SetupContext.INDEX_SETUP_ARCHIVE_LOCATION_URI.
On 16/11/2015 8:58 PM, Stephan Herrmann wrote:
> Trying to define an Oomph setup for a family of interdependent Xtext
> DSLs, I'm getting what looks like random results, not sure what could
> cause such non-determinism:
>
> It all boils down to situations where the result of the very first
> mwe2 launch is not visible to downstream launches which depend on it.
>
> Still the way this fails varies.
>
> Sometimes class org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher
> cannot be found by the launch (only for the first launch, despite the
> fact that I have an explicit project build before the launch).
>
> Sometimes it seems all attempts to refresh the project have no effect,
> I have project refreshing enabled in the launch configuration and
> additionally placed project build tasks with "refresh=true" between
> launches. Still a manual refresh after oomph's completion reveals new
> resources that previously weren't detected.
>
> Another failure manifests as the following NullPointerException which
> also seems to fail the corresponding launch configuration.
> java.lang.NullPointerException
> at
> org.eclipse.ui.internal.console.ConsoleView.display(ConsoleView.java:500)
> at
> org.eclipse.ui.internal.console.ConsoleManager$ShowConsoleViewJob.runInUIThread(ConsoleManager.java:326)
> at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:97)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
> at
> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4155)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3772)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
> at
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
>
> Does any of this ring a bell with any oompher?
>
> Any ideas how to debug what might be the root cause behind all this
> spookiness?
> thanks,
> Stephan
>
> PS 1: Things actually improve by simply duplicating the first launch
> task.
>
> PS 2: The very first thing I see in the Error log is the following
> warning, no idea where that broken URL may have been defined, nor do I
> know if this is potentially connected to the above problem:
> org.eclipse.oomph.util.IOExceptionWithCause: unknown protocol: c
> at
> org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl.createInputStream(ECFURIHandlerImpl.java:289)
> at
> org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:360)
> at
> org.eclipse.oomph.setup.internal.core.util.SetupCoreUtil.handleArchiveRedirection(SetupCoreUtil.java:376)
> at
> org.eclipse.oomph.setup.internal.core.util.SetupCoreUtil.configureResourceSet(SetupCoreUtil.java:358)
> at
> org.eclipse.oomph.setup.internal.core.util.SetupCoreUtil.createResourceSet(SetupCoreUtil.java:131)
> at
> org.eclipse.oomph.setup.ui.recorder.RecorderManager.<clinit>(RecorderManager.java:117)
> at
> org.eclipse.oomph.setup.ui.recorder.RecorderManager$Lifecycle.start(RecorderManager.java:941)
> at
> org.eclipse.oomph.setup.ui.SetupUIPlugin$1.run(SetupUIPlugin.java:218)
> and more like this from
> -
> org.eclipse.oomph.setup.ui.SetupUIPlugin.performStartup(SetupUIPlugin.java:344)
> and from
> -
> org.eclipse.oomph.setup.ui.wizards.VariablePage.leavePage(VariablePage.java:598)
> and from
> -
> org.eclipse.oomph.setup.ui.wizards.ProgressPage.saveLocalFiles(ProgressPage.java:961)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: "Random" failures with multiple mwe2 launches depending on each other [message #1715026 is a reply to message #1714990] |
Wed, 18 November 2015 15:19 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
I think I found two reasons, why resources weren't picked up as needed:
(1) concurrency
(2) concurrency
(1) It seems that a launch configuration, which has "Refresh resources upon completion" enabled, performs those refreshes asynchronously. At least this is what I see in org.eclipse.emf.mwe2.launch.shortcut.Mwe2LaunchDelegate.launch().
(2) Additionally, I (think I) saw concurrent execution of launch tasks.
Lesson from (1): refresh via launch configuration is not suitable for coordinating several mwe2 runs.
Question regarding (2): is it true that Oomph can perform several taks / launches in parallel? If so, the order shown in any list of tasks should be taken with a (big) grain of salt, specifying predecessors for each logical dependency seems to be required, yes?
The above still doesn't explain, why manual refresh after oomph completion still revealed more resources, though ..
Stephan
|
|
|
| Re: &quot;Random&quot; failures with multiple mwe2 launches depending on each other [message #1715029 is a reply to message #1715026] |
Wed, 18 November 2015 15:40 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Stephan,
Comments below.
On 18/11/2015 4:19 PM, Stephan Herrmann wrote:
> I think I found two reasons, why resources weren't picked up as needed:
> (1) concurrency
> (2) concurrency
>
> :)
Yes, I have a feeling about the refresh being done on other threads, and
causing other things to happen, a build for example...
>
> (1) It seems that a launch configuration, which has "Refresh resources
> upon completion" enabled, performs those refreshes asynchronously. At
> least this is what I see in
> org.eclipse.emf.mwe2.launch.shortcut.Mwe2LaunchDelegate.launch().
We wait for the process to finish, but then we proceed with the next task...
>
> (2) Additionally, I (think I) saw concurrent execution of launch tasks.
We wait in the loop for the launched process to terminate.
for (;;)
{
Thread.sleep(1000);
if (context.isCanceled())
{
launch.terminate();
return;
}
if (launch.isTerminated())
{
HISTORY.setProperty(launcher, processes.length > 0 ?
Integer.toString(processes[0].getExitValue()) : "-1");
return;
}
}
> Lesson from (1): refresh via launch configuration is not suitable for
> coordinating several mwe2 runs.
Do you have project build tasks between launches? That might help
ensure that a refresh is finished (the build task can also do a refresh)
and a build would definitely be done so any changes needed from the
first launch are available in the next one...
>
> Question regarding (2): is it true that Oomph can perform several taks
> / launches in parallel? If so, the order shown in any list of tasks
> should be taken with a (big) grain of salt, specifying predecessors
> for each logical dependency seems to be required, yes?
No they aren't done in parallel. They'll be done in the order you see
them on the confirmation page, which generally respect the order they
are in the source...
>
> The above still doesn't explain, why manual refresh after oomph
> completion still revealed more resources, though ..
Perhaps project build tasks will help, if you aren't already using them
between tasks...
> Stephan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: &amp;quot;Random&amp;quot; failures with multiple mwe2 launches depending on eac [message #1715083 is a reply to message #1715044] |
Thu, 19 November 2015 06:39 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Stephan,
Comments below.
On 18/11/2015 7:31 PM, Stephan Herrmann wrote:
> Meanwhile I identified the PEBKAC involved: I had defined lots of
> project build tasks, but then I got confused by the kinds of patterns,
> so I ended up building all projects matching patterns like
> "*mydsl.model" etc. (effect: nothing). Only the final build tasks
> actually worked with pattern "File at **/*.xtend".
Yes, there is an outstanding bug to provide hand written descriptions
for all properties.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=431147
It's quite a bit of work, but obviously a worthwhile effort...
>
> So if I may propose s.t. that would have saved me some hours of
> searching in the wrong place: please add validations for patterns, so
> we get immediate feedback when specifying a glob or ant pattern where
> a regex is expected and vice versa. Unfortunately, the cool
> outline-as-preview doesn't work for pattern matching against projects
> which we don't yet have ...
I'll have to have a look. Many features are of type string so that they
allow variables so they might not be contextually valid until
expanded. In this case, was your pattern actually syntactically
invalid? Or did it just not match as you expected, in which case better
logging about that's actually matched might be the most helpful thing.
(I've not looked at all at what the build task is logging.)
>
> BTW: Another source for concurrency is
> org.eclipse.egit.core.op.ConnectProviderOperation performing resource
> refreshes at unknown points in time.
Hmmm.
> I wonder, it it would help if oomph offers a task: WaitForIdle, to let
> all those things cool down when needed?
Eclipse is never idle! :-P I'm not sure why it's necessary for the
EGit logic that connects the project to the team provider must do a
refresh...
> With that I could continue letting the launch configurations define
> what needs refreshing and just define a checkpoint when all pending
> refreshing should be awaited.
It's hard to imagine how to detect idleness...
>
> Stephan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: &amp;amp;quot;Random&amp;amp;quot; failures with multiple mwe2 launches dependin [message #1715294 is a reply to message #1715122] |
Sat, 21 November 2015 06:12 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Stephan,
Comments below.
On 19/11/2015 12:58 PM, Stephan Herrmann wrote:
> Quote:
>> In this case, was your pattern actually syntactically invalid?
>
>
> I'm not 100% on firm grounds here, but I don't think a regex can
> legally start with at star, so flagging "*foo" and "**/foo" would
> already go a long way. I'm kind of surprised that Pattern.compile()
> didn't throw a PatternSyntaxException, or did it and the exception
> just got swallowed?
It sounds like this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=431458
>
> Quote:
>> It's hard to imagine how to detect idleness...
>
> Sure, Eclipse is always busy :) but I'd imagine the following three
> together should give quite good indication:
> 1. a syncExec or two to check the state of the UI thread
> 2. org.eclipse.core.internal.jobs.JobManager.isIdle()
> 3. waiting for active builds.
>
> Actually, org.eclipse.core.runtime.jobs.IJobManager.join(Object,
> IProgressMonitor) should be able to cover (2) and (3).
A join would be very clean, but which family or families should we
join? And given we're performing using a Job, the manager definitely
won't be idle...
I imagine that the build task, doing a refresh first, and then a build,
that the build itself should be waiting for the refreshes and any other
build (there shouldn't be any because auto build is disabled) to finish...
In any case, we'd need at least some kind of test case/scenario where
there are problems to understand them and learn how best to address then.
>
> Stephan
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Dec 26 11:28:26 GMT 2024
Powered by FUDForum. Page generated in 0.48880 seconds |
] 
Search
Help
Register
Login
Home
