[
https://issues.apache.org/jira/browse/IVYDE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906921#comment-13906921
]
Carsten Pfeiffer commented on IVYDE-259:
----------------------------------------
The change in IvyClasspathContainer (asyncExec -> syncExec) may unfortunately
lead to deadlock situations. If the main thread attempts to execute a job while
the resolve job is already running, the main thread waits for the resolve job
to finish. The latter then attempts to syncExec() into the main thread, which
won't work.
{code}
Thread [Worker-4] (Suspended)
waiting for: RunnableLock (id=122)
Object.wait(long) line: not available [native method]
RunnableLock(Object).wait() line: 503
Synchronizer.syncExec(Runnable) line: 187
Display.syncExec(Runnable) line: 4330
IvyClasspathContainerImpl.setClasspathEntries(IClasspathEntry[]) line:
148
IvyClasspathContainerImpl.updateClasspathEntries(IClasspathEntry[])
line: 144
IvyClasspathResolver.postBatchResolve() line: 40
IvyResolveJob.doRun(IProgressMonitor) line: 263
IvyResolveJob.run(IProgressMonitor) line: 85
Worker.run() line: 54
{code}
{code}
Thread [main] (Suspended)
owns: RunnableLock (id=122)
waited by: Thread [Worker-4] (Suspended)
waiting for: Object (id=123)
Object.wait(long) line: not available [native method]
Object.wait() line: 503
ThreadJob.waitForRun(ThreadJob, IProgressMonitor, InternalJob, Thread)
line: 272
ThreadJob.joinRun(ThreadJob, IProgressMonitor) line: 199
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 92
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 286
WorkManager.checkIn(ISchedulingRule, IProgressMonitor) line: 118
Workspace.prepareOperation(ISchedulingRule, IProgressMonitor) line:
2282
Folder(Resource).refreshLocal(int, IProgressMonitor) line: 1655
ExternalFoldersManager.createLinkFolder(IPath, boolean, IProject,
IProgressMonitor) line: 155
ExternalFoldersManager.createLinkFolder(IPath, boolean,
IProgressMonitor) line: 145
ExternalFolderChange.updateExternalFoldersIfNecessary(boolean,
IProgressMonitor) line: 48
SetContainerOperation(ChangeClasspathOperation).classpathChanged(ClasspathChange,
boolean) line: 62
SetContainerOperation.executeOperation() line: 110
SetContainerOperation(JavaModelOperation).run(IProgressMonitor) line:
728
Workspace.run(IWorkspaceRunnable, ISchedulingRule, int,
IProgressMonitor) line: 2344
SetContainerOperation(JavaModelOperation).runOperation(IProgressMonitor) line:
793
JavaCore.setClasspathContainer(IPath, IJavaProject[],
IClasspathContainer[], IProgressMonitor) line: 4952
IvyClasspathContainerImpl.notifyUpdateClasspathEntries() line: 172
IvyClasspathContainerImpl$1.run() line: 162
RunnableLock.run() line: 35
Synchronizer.runAsyncMessages(boolean) line: 135
Display.runAsyncMessages(boolean) line: 3563
Display.readAndDispatch() line: 3212
...
{code}
> duplicate setup's added to setuplist in prefs file
> --------------------------------------------------
>
> Key: IVYDE-259
> URL: https://issues.apache.org/jira/browse/IVYDE-259
> Project: IvyDE
> Issue Type: Bug
> Environment: ivyde hudson build
> Reporter: Stephen Haberman
> Assignee: Nicolas Lalevée
> Priority: Minor
> Fix For: 2.2.0.beta1
>
>
> I'm using the latest hudson build and the new
> .settings/org.apache.ivyde.eclipse.prefs file is churning a lot. In the
> latest diff, the setting org.apache.ivyde.eclipse.standlaoneretrieve had
> changed from:
> <?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>
> <setuplist>
> <setup name\="dependencies">
> <ivysettings loadondemand\="false"
> path\="${workspace_loc\:project/ivysettings.xml}"/>
> <ivyxml path\="ivy.xml"/>
> <retrieve confs\="*"
> pattern\="bin/lib/[conf]/[type]s/[artifact].[ext]" sync\="true"
> types\="jar,source"/>
> </setup>
> (this <setup/> was repeated 5 times)
> To the same thing but with <setup/> repeated 6 times.
> It seems to be adding new setups but not taking out the old ones. I'm not
> really sure what is triggering the new (duplicate) <setup/> to be added. I
> just notice after using Eclipse for awhile that the files have changed.
> Also, the setting name "standlaoneretrieve" has a typo, "laone" should be
> "alone".
> Apologies if I shouldn't be using the hudson build or reporting bugs for it
> here.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
