You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Andree Wormuth (JIRA)" <ji...@apache.org> on 2016/10/26 12:32:58 UTC
[jira] [Comment Edited] (IVYDE-385) IvyFileContentDescriber hangs
with huge XML files
[ https://issues.apache.org/jira/browse/IVYDE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15608274#comment-15608274 ]
Andree Wormuth edited comment on IVYDE-385 at 10/26/16 12:32 PM:
-----------------------------------------------------------------
*Background:*
I have several non-java projects in my eclipse workspace which contain really huge XML files ( some hundreds of MBs or even gt 1 GB).
Of course it would be impossible to edit these within eclipse, but I wish to access several other configuration files from these project within eclipse, so that's why these "General Projects" exist.
From time to time while traversing these projects - not opening the huge files, mind you - Eclipse starts to take all available CPU power and hangs, consuming all available memory and working excessively. After about half an hour it's done and everything's fine again.
I connected with Java Mission Control to the java process during the latest "hang period" and dug out the stacktrace listed above.
To me it seems that the {{IvyFileContentDescriber}} is asked to describe the content of at least one of these huge XML files and opens it to do so - which is nigh impossible and takes a lot of time.
I checked out the latest version from {{svn trunk}} and found that {{IvyFileContentDescriber}} has been removed as "unnecessary file", so - just as expected - I have not been able to reproduce the problem since I have installed the latest nightly built from the trunk.
Unfortunately I haven't been able to build a version from branch {{2.2.final}}, always getting a "inter-plug-in dependency" issue, though I have installed the plug-ins as described in doc:
{quote}
[java] [eclipse.buildScript] Some inter-plug-in dependencies have not been satisfied.
Bundle org.apache.ivyde.eclipse.resolvevisualizer:
Missing required plug-in org.eclipse.zest.core_[1.2.0,2.0.0).
Missing required plug-in org.eclipse.zest.layouts_[1.1.0,2.0.0).
Bundle org.apache.ivyde.eclipse:
Another singleton version selected: org.apache.ivyde.eclipse_2.3.0.beta1-201610261253-dev
{quote}
Because of that and because I do not know why Eclipse takes each XML file it finds in a general project and asks the IvyDE plugin to handle it, I am not really able to suggest a solution or improvement here, let alone a patch.
But I fancy it should be possible to avoid opening all these files to perform the condition check, or at least to fail faster.
Perhaps it would be possible to create another bugfix release for 2.2. without these files?
was (Author: andree.wormuth):
*Background:*
I have several non-java projects in my eclipse workspace which contain really huge XML files ( some hundreds of MBs or even gt 1 GB).
Of course it would be impossible to edit these within eclipse, but I wish to access several other configuration files from these project within eclipse, so that's why these "General Projects" exist.
From time to time while traversing these projects - not opening the huge files, mind you - Eclipse starts to take all available CPU power and hangs, consuming all available memory and working excessively. After about half an hour it's done and everything's fine again.
I connected with Java Mission Control to the java process during the latest "hang period" and dug out the stacktrace listed above.
To me it seems that the {{IvyFileContentDescriber}} is asked to describe the content of at least one of these huge XML files and opens it to do so - which is nigh impossible and takes a lot of time.
I checked out the latest version from {{svn trunk}} and found that {{IvyFileContentDescriber}} has been removed as "unnecessary file", so - just as expected - I have not been able to reproduce the problem since I have installed the latest nightly built from the trunk.
Unfortunately I haven't been able to build a version from branch {{2.2.final}}, always getting a "inter-plug-in dependency" issue, though I have installed the plug-ins as described in doc:
{quote}
[java] [eclipse.buildScript] Some inter-plug-in dependencies have not been satisfied.
Bundle org.apache.ivyde.eclipse.resolvevisualizer:
Missing required plug-in org.eclipse.zest.core_[1.2.0,2.0.0).
Missing required plug-in org.eclipse.zest.layouts_[1.1.0,2.0.0).
Bundle org.apache.ivyde.eclipse:
Another singleton version selected: org.apache.ivyde.eclipse_2.3.0.beta1-201610261253-dev
{quote}
Because of that and because I do not know why Eclipse takes each XML file it finds in a general project and asks the IvyDE plugin to handle it, I am not really able to suggest a solution or improvement here, let alone a patch.
But I fancy it should be possible to avoid opening all these files.
Perhaps it would be possible to create another bugfix release for 2.2. without these files?
> IvyFileContentDescriber hangs with huge XML files
> -------------------------------------------------
>
> Key: IVYDE-385
> URL: https://issues.apache.org/jira/browse/IVYDE-385
> Project: IvyDE
> Issue Type: Improvement
> Affects Versions: 2.2.0.final
> Environment: Each of the recent Eclipse versions (Helios. Mars, Neon)
> Win 10
> Java 8
> Reporter: Andree Wormuth
>
> The {{IvyFileContentDescriber}} seems to open each XML it's presented to check if it's an ivy file:
> {quote}java.io.FileInputStream.readBytes line: not available native method
> java.io.FileInputStream.read line: 255
> org.eclipse.core.internal.resources.ContentDescriptionManager$LazyFileInputStream.read line: 173
> java.io.InputStream.read line: 101
> org.eclipse.core.internal.content.LazyInputStream.loadBlock line: 101
> org.eclipse.core.internal.content.LazyInputStream.ensureAvailable line: 65
> org.eclipse.core.internal.content.LazyInputStream.read line: 139
> org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read line: not available
> org.apache.xerces.impl.io.UTF8Reader.read line: not available
> org.apache.xerces.impl.XMLEntityScanner.load line: not available
> org.apache.xerces.impl.XMLEntityScanner.scanContent line: not available
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent line: not available
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch line: not available
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument line: not available
> org.apache.xerces.parsers.XML11Configuration.parse line: not available
> org.apache.xerces.parsers.XML11Configuration.parse line: not available
> org.apache.xerces.parsers.XMLParser.parse line: not available
> org.apache.xerces.parsers.AbstractSAXParser.parse line: not available
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse line: not available
> org.apache.xerces.jaxp.SAXParserImpl.parse line: not available
> org.apache.ivyde.internal.eclipse.XMLHelper.parse line: 76
> org.apache.ivyde.internal.eclipse.ui.editors.IvyFileContentDescriber.checkCriteria line: 70
> org.apache.ivyde.internal.eclipse.ui.editors.IvyFileContentDescriber.describe line: 53
> org.eclipse.core.internal.content.ContentTypeCatalog.describe line: 229
> org.eclipse.core.internal.content.ContentTypeCatalog.collectMatchingByContents line: 201
> org.eclipse.core.internal.content.ContentTypeCatalog.internalFindContentTypesFor line: 414
> org.eclipse.core.internal.content.ContentTypeCatalog.internalFindContentTypesFor line: 461
> org.eclipse.core.internal.content.ContentTypeCatalog.getDescriptionFor line: 357
> org.eclipse.core.internal.content.ContentTypeCatalog.getDescriptionFor line: 371
> org.eclipse.core.internal.content.ContentTypeMatcher.getDescriptionFor line: 76
> org.eclipse.core.internal.resources.ContentDescriptionManager.readDescription line: 453
> org.eclipse.core.internal.resources.ContentDescriptionManager.getDescriptionFor line: 363
> org.eclipse.core.internal.resources.File.getContentDescription line: 263
> org.eclipse.ui.internal.ide.model.WorkbenchResource.testContentTypeProperty line: 148
> org.eclipse.ui.internal.ide.model.WorkbenchResource.testAttribute line: 115
> org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.preciselyMatches line: 512
> org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.isEnabledFor line: 481
> org.eclipse.ui.internal.ActionExpression$AndExpression.isEnabledFor line: 131
> org.eclipse.ui.internal.ActionExpression$SingleExpression.isEnabledFor line: 716
> org.eclipse.ui.internal.ActionExpression.isEnabledFor line: 1022
> org.eclipse.ui.internal.decorators.DecoratorDefinition.isEnabledFor line: 282
> org.eclipse.ui.internal.decorators.DecoratorManager.getDecoratorsFor line: 323
> org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecoratorsFor line: 333
> org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations line: 358
> org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached line: 367
> org.eclipse.ui.internal.decorators.DecorationScheduler$1.run line: 327
> org.eclipse.core.internal.jobs.Worker.run line: 55{quote}
> This fails if a project contains huge XML files.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)