[JBoss JIRA] (JBDS-1985) Synchronizing a VDB takes too long in 7.4.2
by Nick Boldt (Commented) (JIRA)
[ https://issues.jboss.org/browse/JBDS-1985?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-1985:
----------------------------------
Finally got a clean build -- seems that some tests fail to run on RHEL5 or RHEL6 but are happy on RHEL4. That's not a good sign.
Build:
https://hudson.qa.jboss.com/hudson/view/DevStudio_Stable_Branch/job/jboss...
Update Site / Zip:
http://download.jboss.org/jbosstools/builds/staging/jbosstools-teiid-desi...
http://download.jboss.org/jbosstools/builds/staging/jbosstools-teiid-desi...
Barry or John, can you verify this is fixed and resolve this bug if so?
> Synchronizing a VDB takes too long in 7.4.2
> -------------------------------------------
>
> Key: JBDS-1985
> URL: https://issues.jboss.org/browse/JBDS-1985
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Support Patch
> Security Level: Public(Everyone can see)
> Components: teiid
> Affects Versions: 4.1.1.GA
> Reporter: Johnathon Lee
> Assignee: Barry LaFond
> Fix For: 4.1.1.GA
>
> Attachments: JBDS1985.upversion.patch.txt, org.teiid.designer.core.patch, org.teiid.designer.dqp.patch, org.teiid.designer.vdb.patch, org.teiid.designer.vdb.test.patch, org.teiid.designer.vdb.ui.patch, TEIIDDES-1200-7.4.2-Patch-A.zip, TEIIDDES_1200.zip, UdfManager.java.patch, UdfUiPlugin.java.patch, VdbUtil.java.patch
>
>
> Synchronizing a big VDB in version 7.4.2 (JBDS 4.1.1) takes 30 minutes versus 2 minutes in 7.1.1 (JBDS 4.1.0)
> Investigating/debug noted 2 areas.
> 1) New UdfManager is not caching a FunctionLibrary and each SQL validation is creating a new instance. (needs a fix)
> 2) Synchronizing a VDB is hammering the ChecksumUtil.computeChecksum() during the VDB's resource build processing
> 3) PreviewManager is using a new Vdb() object to determine if "preview = true" and version #. However, it's heavy weight and currently the Vdb() is registering for events, but is not being Unregistered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBDS-1985) Synchronizing a VDB takes too long in 7.4.2
by Nick Boldt (Commented) (JIRA)
[ https://issues.jboss.org/browse/JBDS-1985?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-1985:
----------------------------------
More test failures, this time on https://hudson.qa.jboss.com/hudson/computer/vmg17-rhel5-x86_64/:
https://hudson.qa.jboss.com/hudson/view/DevStudio_Stable_Branch/job/jboss...
{code}
[INFO] org.teiid.designer.metamodels.relationship.test ... FAILURE [14.126s]
[INFO] org.teiid.designer.test.feature ................... SKIPPED
{code}
https://hudson.qa.jboss.com/hudson/view/DevStudio_Stable_Branch/job/jboss...
{code}
!ENTRY org.eclipse.osgi 4 0 2011-12-22 22:45:08.081
!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
at org.eclipse.swt.SWT.error(SWT.java:4109)
at org.eclipse.swt.widgets.Display.createDisplay(Display.java:902)
at org.eclipse.swt.widgets.Display.create(Display.java:890)
at org.eclipse.swt.graphics.Device.<init>(Device.java:154)
at org.eclipse.swt.widgets.Display.<init>(Display.java:499)
at org.eclipse.swt.widgets.Display.<init>(Display.java:490)
at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:708)
at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:145)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:88)
at org.codehaus.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:21)
at org.codehaus.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:109)
at org.codehaus.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:27)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
{code}
> Synchronizing a VDB takes too long in 7.4.2
> -------------------------------------------
>
> Key: JBDS-1985
> URL: https://issues.jboss.org/browse/JBDS-1985
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Support Patch
> Security Level: Public(Everyone can see)
> Components: teiid
> Affects Versions: 4.1.1.GA
> Reporter: Johnathon Lee
> Assignee: Barry LaFond
> Fix For: 4.1.1.GA
>
> Attachments: JBDS1985.upversion.patch.txt, org.teiid.designer.core.patch, org.teiid.designer.dqp.patch, org.teiid.designer.vdb.patch, org.teiid.designer.vdb.test.patch, org.teiid.designer.vdb.ui.patch, TEIIDDES-1200-7.4.2-Patch-A.zip, TEIIDDES_1200.zip, UdfManager.java.patch, UdfUiPlugin.java.patch, VdbUtil.java.patch
>
>
> Synchronizing a big VDB in version 7.4.2 (JBDS 4.1.1) takes 30 minutes versus 2 minutes in 7.1.1 (JBDS 4.1.0)
> Investigating/debug noted 2 areas.
> 1) New UdfManager is not caching a FunctionLibrary and each SQL validation is creating a new instance. (needs a fix)
> 2) Synchronizing a VDB is hammering the ChecksumUtil.computeChecksum() during the VDB's resource build processing
> 3) PreviewManager is using a new Vdb() object to determine if "preview = true" and version #. However, it's heavy weight and currently the Vdb() is registering for events, but is not being Unregistered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBDS-1985) Synchronizing a VDB takes too long in 7.4.2
by Nick Boldt (Issue Comment Edited) (JIRA)
[ https://issues.jboss.org/browse/JBDS-1985?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-1985 at 12/22/11 4:17 PM:
------------------------------------------------------------
patch applied to upversion to 7.4.3. Respinning:
https://hudson.qa.jboss.com/hudson/view/DevStudio_Stable_Branch/job/jboss...
Tests failed when run on RHEL6, which we've never done before. Respinning #695 on RHEL5 to see if it fails again...
was (Author: nickboldt):
patch applied to upversion to 7.4.3. Respinning:
https://hudson.qa.jboss.com/hudson/view/DevStudio_Stable_Branch/job/jboss...
> Synchronizing a VDB takes too long in 7.4.2
> -------------------------------------------
>
> Key: JBDS-1985
> URL: https://issues.jboss.org/browse/JBDS-1985
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Support Patch
> Security Level: Public(Everyone can see)
> Components: teiid
> Affects Versions: 4.1.1.GA
> Reporter: Johnathon Lee
> Assignee: Barry LaFond
> Fix For: 4.1.1.GA
>
> Attachments: JBDS1985.upversion.patch.txt, org.teiid.designer.core.patch, org.teiid.designer.dqp.patch, org.teiid.designer.vdb.patch, org.teiid.designer.vdb.test.patch, org.teiid.designer.vdb.ui.patch, TEIIDDES-1200-7.4.2-Patch-A.zip, TEIIDDES_1200.zip, UdfManager.java.patch, UdfUiPlugin.java.patch, VdbUtil.java.patch
>
>
> Synchronizing a big VDB in version 7.4.2 (JBDS 4.1.1) takes 30 minutes versus 2 minutes in 7.1.1 (JBDS 4.1.0)
> Investigating/debug noted 2 areas.
> 1) New UdfManager is not caching a FunctionLibrary and each SQL validation is creating a new instance. (needs a fix)
> 2) Synchronizing a VDB is hammering the ChecksumUtil.computeChecksum() during the VDB's resource build processing
> 3) PreviewManager is using a new Vdb() object to determine if "preview = true" and version #. However, it's heavy weight and currently the Vdb() is registering for events, but is not being Unregistered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBIDE-10008) Null Pointer Exception in XModelEntityImpl.getRequiredChildren() method
by Daniel Azarov (Created) (JIRA)
Null Pointer Exception in XModelEntityImpl.getRequiredChildren() method
-----------------------------------------------------------------------
Key: JBIDE-10008
URL: https://issues.jboss.org/browse/JBIDE-10008
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: common/jst/core
Affects Versions: 3.3.0.M3
Reporter: Daniel Azarov
Assignee: Viacheslav Kabanovich
Fix For: 3.3.0.Beta1
java.lang.NullPointerException
at org.jboss.tools.common.meta.impl.XModelEntityImpl.getRequiredChildren(XModelEntityImpl.java:386)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.loadChildren(XModelObjectLoaderUtil.java:309)
at org.jboss.tools.common.model.filesystems.impl.FileSystemsLoaderUtil.loadChildren(FileSystemsLoader.java:272)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.load(XModelObjectLoaderUtil.java:98)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.loadChildren(XModelObjectLoaderUtil.java:320)
at org.jboss.tools.common.model.filesystems.impl.FileSystemsLoaderUtil.loadChildren(FileSystemsLoader.java:272)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.load(XModelObjectLoaderUtil.java:98)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.loadChildren(XModelObjectLoaderUtil.java:320)
at org.jboss.tools.common.model.filesystems.impl.FileSystemsLoaderUtil.loadChildren(FileSystemsLoader.java:272)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.load(XModelObjectLoaderUtil.java:98)
at org.jboss.tools.common.model.util.XModelObjectLoaderUtil.load(XModelObjectLoaderUtil.java:688)
at org.jboss.tools.common.model.filesystems.impl.FileSystemsLoader.load(FileSystemsLoader.java:95)
at org.jboss.tools.common.model.loaders.impl.RootLoaderImpl.load(RootLoaderImpl.java:33)
at org.jboss.tools.common.model.impl.XModelImpl.load(XModelImpl.java:410)
at org.jboss.tools.common.model.XModelFactory.createInstance(XModelFactory.java:36)
at org.jboss.tools.common.model.XModelFactory.getModel(XModelFactory.java:29)
at org.jboss.tools.common.model.project.ModelNature.createProject(ModelNature.java:134)
at org.jboss.tools.common.model.project.ModelNature.setProject(ModelNature.java:64)
at org.eclipse.core.internal.resources.NatureManager.createNature(NatureManager.java:234)
at org.eclipse.core.internal.resources.Project.getNature(Project.java:448)
at org.jboss.tools.common.model.util.EclipseResourceUtil.getModelNature(EclipseResourceUtil.java:264)
at org.jboss.tools.jst.web.model.helpers.InnerModelHelper.createXModel(InnerModelHelper.java:36)
at org.jboss.tools.seam.internal.core.scanner.lib.ClassPath.init(ClassPath.java:65)
at org.jboss.tools.seam.internal.core.SeamProject.setProject(SeamProject.java:267)
at org.eclipse.core.internal.resources.NatureManager.createNature(NatureManager.java:234)
at org.eclipse.core.internal.resources.Project.getNature(Project.java:448)
at org.jboss.tools.seam.core.SeamCorePlugin.getSeamProject(SeamCorePlugin.java:206)
at org.jboss.tools.seam.internal.core.validation.SeamProjectPropertyValidator.validateProject(SeamProjectPropertyValidator.java:156)
at org.jboss.tools.seam.internal.core.validation.SeamProjectPropertyValidator.validateInJob(SeamProjectPropertyValidator.java:132)
at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBIDE-10111) ConcurrentModificationException after closing Seam War project
by Denis Golovin (Created) (JIRA)
ConcurrentModificationException after closing Seam War project
--------------------------------------------------------------
Key: JBIDE-10111
URL: https://issues.jboss.org/browse/JBIDE-10111
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: common/jst/core
Affects Versions: 3.3.0.Beta1
Reporter: Denis Golovin
Assignee: Alexey Kazakov
Now Test case in steps to reproduce fails on last step with bunch of exceptions. First is throws exception
{noformat}org.eclipse.core.internal.resources.ResourceException: Resource '/seam22hib' is not open.
at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:150)
at org.eclipse.core.internal.resources.Resource.findMarkers(Resource.java:1007)
at org.jboss.tools.jst.web.kb.internal.validation.KBValidator.findBuilderOrderMarker(KBValidator.java:129)
at org.jboss.tools.jst.web.kb.internal.validation.KBValidator.validateBuilderOrder(KBValidator.java:89)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateBuilderOrder(ELValidator.java:482)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.shouldValidate(ELValidator.java:468)
at org.jboss.tools.common.validation.ValidationContext.init(ValidationContext.java:86)
at org.jboss.tools.common.validation.ValidationContext.<init>(ValidationContext.java:42)
at org.jboss.tools.common.validation.ContextValidationHelper.getValidationContextManager(ContextValidationHelper.java:161)
at org.jboss.tools.common.validation.ContextValidationHelper.getValidationContextManager(ContextValidationHelper.java:153)
at org.jboss.tools.common.validation.ValidatorManager.validateInJob(ValidatorManager.java:65)
at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54){noformat}
then
{noformat}java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$KeyIterator.next(HashMap.java:845)
at org.jboss.tools.common.model.project.ext.AbstractClassPathMonitor.syncProcessedPaths(AbstractClassPathMonitor.java:110)
at org.jboss.tools.seam.internal.core.scanner.lib.ClassPath.process(ClassPath.java:73)
at org.jboss.tools.seam.internal.core.scanner.lib.ClassPath.build(ClassPath.java:178)
at org.jboss.tools.seam.internal.core.SeamProject.build(SeamProject.java:371)
at org.jboss.tools.seam.core.SeamCoreBuilder.build(SeamCoreBuilder.java:50)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54){noformat}
and finally
{noformat}java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$KeyIterator.next(HashMap.java:845)
at org.jboss.tools.common.model.project.ext.AbstractClassPathMonitor.syncProcessedPaths(AbstractClassPathMonitor.java:110)
at org.jboss.tools.seam.internal.core.scanner.lib.ClassPath.process(ClassPath.java:73)
at org.jboss.tools.seam.internal.core.scanner.lib.ClassPath.build(ClassPath.java:178)
at org.jboss.tools.seam.internal.core.SeamProject.build(SeamProject.java:371)
at org.jboss.tools.seam.core.SeamCoreBuilder.build(SeamCoreBuilder.java:50)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54){noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBDS-1985) Synchronizing a VDB takes too long in 7.4.2
by Nick Boldt (Commented) (JIRA)
[ https://issues.jboss.org/browse/JBDS-1985?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-1985:
----------------------------------
patch applied to upversion to 7.4.3. Respinning:
https://hudson.qa.jboss.com/hudson/view/DevStudio_Stable_Branch/job/jboss...
> Synchronizing a VDB takes too long in 7.4.2
> -------------------------------------------
>
> Key: JBDS-1985
> URL: https://issues.jboss.org/browse/JBDS-1985
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Support Patch
> Security Level: Public(Everyone can see)
> Components: teiid
> Affects Versions: 4.1.1.GA
> Reporter: Johnathon Lee
> Assignee: Barry LaFond
> Fix For: 4.1.1.GA
>
> Attachments: JBDS1985.upversion.patch.txt, org.teiid.designer.core.patch, org.teiid.designer.dqp.patch, org.teiid.designer.vdb.patch, org.teiid.designer.vdb.test.patch, org.teiid.designer.vdb.ui.patch, TEIIDDES-1200-7.4.2-Patch-A.zip, TEIIDDES_1200.zip, UdfManager.java.patch, UdfUiPlugin.java.patch, VdbUtil.java.patch
>
>
> Synchronizing a big VDB in version 7.4.2 (JBDS 4.1.1) takes 30 minutes versus 2 minutes in 7.1.1 (JBDS 4.1.0)
> Investigating/debug noted 2 areas.
> 1) New UdfManager is not caching a FunctionLibrary and each SQL validation is creating a new instance. (needs a fix)
> 2) Synchronizing a VDB is hammering the ChecksumUtil.computeChecksum() during the VDB's resource build processing
> 3) PreviewManager is using a new Vdb() object to determine if "preview = true" and version #. However, it's heavy weight and currently the Vdb() is registering for events, but is not being Unregistered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBDS-1985) Synchronizing a VDB takes too long in 7.4.2
by Barry LaFond (Commented) (JIRA)
[ https://issues.jboss.org/browse/JBDS-1985?page=com.atlassian.jira.plugin.... ]
Barry LaFond commented on JBDS-1985:
------------------------------------
changed hudson job SVN url to 7.4.x branch
> Synchronizing a VDB takes too long in 7.4.2
> -------------------------------------------
>
> Key: JBDS-1985
> URL: https://issues.jboss.org/browse/JBDS-1985
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Support Patch
> Security Level: Public(Everyone can see)
> Components: teiid
> Affects Versions: 4.1.1.GA
> Reporter: Johnathon Lee
> Assignee: Barry LaFond
> Fix For: 4.1.1.GA
>
> Attachments: JBDS1985.upversion.patch.txt, org.teiid.designer.core.patch, org.teiid.designer.dqp.patch, org.teiid.designer.vdb.patch, org.teiid.designer.vdb.test.patch, org.teiid.designer.vdb.ui.patch, TEIIDDES-1200-7.4.2-Patch-A.zip, TEIIDDES_1200.zip, UdfManager.java.patch, UdfUiPlugin.java.patch, VdbUtil.java.patch
>
>
> Synchronizing a big VDB in version 7.4.2 (JBDS 4.1.1) takes 30 minutes versus 2 minutes in 7.1.1 (JBDS 4.1.0)
> Investigating/debug noted 2 areas.
> 1) New UdfManager is not caching a FunctionLibrary and each SQL validation is creating a new instance. (needs a fix)
> 2) Synchronizing a VDB is hammering the ChecksumUtil.computeChecksum() during the VDB's resource build processing
> 3) PreviewManager is using a new Vdb() object to determine if "preview = true" and version #. However, it's heavy weight and currently the Vdb() is registering for events, but is not being Unregistered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months