| Long delay + UI locked when saving MANIFESTs [message #53271] |
Thu, 02 April 2009 09:47  |
Eclipse User |
|
|
|
Hi,
I have a workspace with several (~10) projects - each being built as an
OSGI bundle. I have a large number of dependencies in my target platform
(~200).
When modifying dependencies for a bundle by editing its MANFIEST.MF, I'm
encountering a long (30 - 45 second) UI freeze when I save the resource.
This occurs before any required re-building of the workspace kicks in.
I've recently upgraded from Eclipse 3.3 to Eclipse 3.4(.2) and did not
experience this when developing in 3.3.
During the 'freeze' - CPU ramps right up throughout the duration - and
most of the time we seem to be in 'resolveState' - having lots of fun in
GroupingChecker....
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
at
org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
at
org.eclipse.osgi.internal.module.GroupingChecker.isConsisten tInternal(GroupingChecker.java:103)
at
org.eclipse.osgi.internal.module.GroupingChecker.isConsisten t(GroupingChecker.java:85)
at
org.eclipse.osgi.internal.module.ResolverImpl.addConflicts(R esolverImpl.java:734)
at
org.eclipse.osgi.internal.module.ResolverImpl.getConflicts(R esolverImpl.java:711)
at
org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:629)
at
org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:594)
at
org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:539)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
at
org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:573)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles (ResolverImpl.java:501)
at
org.eclipse.osgi.internal.module.ResolverImpl.resolve(Resolv erImpl.java:388)
- locked <0x1339fe10> (a
org.eclipse.osgi.internal.module.ResolverImpl)
at
org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:428)
- locked <0x132553f8> (a
org.eclipse.osgi.internal.resolver.UserState)
at
org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:488)
at
org.eclipse.pde.internal.core.MinimalState.internalResolveSt ate(MinimalState.java:206)
- locked <0x13255448> (a org.eclipse.pde.internal.core.PDEState)
at
org.eclipse.pde.internal.core.MinimalState.resolveState(Mini malState.java:201)
at
org.eclipse.pde.internal.core.PluginModelManager.modelsChang ed(PluginModelManager.java:161)
This 30 - 45 sec lag when updating MANIFESTS is making 3.4 pretty much
unusable for me on fairly large projects.
Is this a known issue? Is there anything I can tweak in my configuration
to prevent this?
Thanks,
Dave
|
|
|
|
|
|
|
| Re: Long delay + UI locked when saving MANIFESTs [message #53475 is a reply to message #53345] |
Fri, 03 April 2009 04:16  |
| Eclipse User |
|
|
|
Eric,
you're right, this is definetely not very practical but a workaround for
this problem. I hope, that this issue is addressed very soon
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=216934) to make this hack
obsolete...
Regards,
Stefan.
Eric Rizzo schrieb:
> On 4/2/2009 10:01 AM, Stefan Roeck wrote:
>> Hi Dave,
>>
>> we had the same problem and found out that the uses-constraints in our
>> target platform bundles are a problem for resolving. There are two
>> possible solutions (assuming that you don't need uses-constraints, i.e.
>> don't have multiple versions of the same bundle in your target platform):
>> - Set VM-Parameter osgi.resolver.usesMode=ignore
>> - Remove all uses-constraints from manifest files
>
> Do you mean remove them from the manifests in the target platform? That
> doesn't seem very practical given a target platform that is based on one
> of the EPP packages like "Eclipse for JEE Developers", is it?
>
> Eric
|
|
|
| Re: Long delay + UI locked when saving MANIFESTs [message #594525 is a reply to message #53271] |
Thu, 02 April 2009 10:01 |
| Eclipse User |
|
|
|
Hi Dave,
we had the same problem and found out that the uses-constraints in our
target platform bundles are a problem for resolving. There are two
possible solutions (assuming that you don't need uses-constraints, i.e.
don't have multiple versions of the same bundle in your target platform):
- Set VM-Parameter osgi.resolver.usesMode=ignore
- Remove all uses-constraints from manifest files
Hope that helps,
Stefan.
dave irving schrieb:
> Hi,
>
> I have a workspace with several (~10) projects - each being built as an
> OSGI bundle. I have a large number of dependencies in my target platform
> (~200).
>
> When modifying dependencies for a bundle by editing its MANFIEST.MF, I'm
> encountering a long (30 - 45 second) UI freeze when I save the resource.
> This occurs before any required re-building of the workspace kicks in.
>
> I've recently upgraded from Eclipse 3.3 to Eclipse 3.4(.2) and did not
> experience this when developing in 3.3.
>
> During the 'freeze' - CPU ramps right up throughout the duration - and
> most of the time we seem to be in 'resolveState' - having lots of fun in
> GroupingChecker....
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker.isConsisten tInternal(GroupingChecker.java:103)
>
> at
> org.eclipse.osgi.internal.module.GroupingChecker.isConsisten t(GroupingChecker.java:85)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.addConflicts(R esolverImpl.java:734)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.getConflicts(R esolverImpl.java:711)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:629)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:594)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:539)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:573)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles (ResolverImpl.java:501)
>
> at
> org.eclipse.osgi.internal.module.ResolverImpl.resolve(Resolv erImpl.java:388)
>
> - locked <0x1339fe10> (a
> org.eclipse.osgi.internal.module.ResolverImpl)
> at
> org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:428)
> - locked <0x132553f8> (a
> org.eclipse.osgi.internal.resolver.UserState)
> at
> org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:488)
> at
> org.eclipse.pde.internal.core.MinimalState.internalResolveSt ate(MinimalState.java:206)
>
> - locked <0x13255448> (a org.eclipse.pde.internal.core.PDEState)
> at
> org.eclipse.pde.internal.core.MinimalState.resolveState(Mini malState.java:201)
>
> at
> org.eclipse.pde.internal.core.PluginModelManager.modelsChang ed(PluginModelManager.java:161)
>
>
> This 30 - 45 sec lag when updating MANIFESTS is making 3.4 pretty much
> unusable for me on fairly large projects.
>
> Is this a known issue? Is there anything I can tweak in my configuration
> to prevent this?
>
> Thanks,
>
> Dave
>
>
|
|
|
| Re: Long delay + UI locked when saving MANIFESTs [message #594543 is a reply to message #53301] |
Thu, 02 April 2009 11:31 |
| Eclipse User |
|
|
|
On 4/2/2009 10:01 AM, Stefan Roeck wrote:
> Hi Dave,
>
> we had the same problem and found out that the uses-constraints in our
> target platform bundles are a problem for resolving. There are two
> possible solutions (assuming that you don't need uses-constraints, i.e.
> don't have multiple versions of the same bundle in your target platform):
> - Set VM-Parameter osgi.resolver.usesMode=ignore
> - Remove all uses-constraints from manifest files
Do you mean remove them from the manifests in the target platform? That
doesn't seem very practical given a target platform that is based on one
of the EPP packages like "Eclipse for JEE Developers", is it?
Eric
> dave irving schrieb:
>> Hi,
>>
>> I have a workspace with several (~10) projects - each being built as
>> an OSGI bundle. I have a large number of dependencies in my target
>> platform (~200).
>>
>> When modifying dependencies for a bundle by editing its MANFIEST.MF,
>> I'm encountering a long (30 - 45 second) UI freeze when I save the
>> resource.
>> This occurs before any required re-building of the workspace kicks in.
>>
>> I've recently upgraded from Eclipse 3.3 to Eclipse 3.4(.2) and did not
>> experience this when developing in 3.3.
>>
>> During the 'freeze' - CPU ramps right up throughout the duration - and
>> most of the time we seem to be in 'resolveState' - having lots of fun
>> in GroupingChecker....
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker.isConsisten tInternal(GroupingChecker.java:103)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker.isConsisten t(GroupingChecker.java:85)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.addConflicts(R esolverImpl.java:734)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.getConflicts(R esolverImpl.java:711)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:629)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:594)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:539)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:573)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles (ResolverImpl.java:501)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolve(Resolv erImpl.java:388)
>>
>> - locked <0x1339fe10> (a org.eclipse.osgi.internal.module.ResolverImpl)
>> at
>> org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:428)
>> - locked <0x132553f8> (a org.eclipse.osgi.internal.resolver.UserState)
>> at
>> org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:488)
>> at
>> org.eclipse.pde.internal.core.MinimalState.internalResolveSt ate(MinimalState.java:206)
>>
>> - locked <0x13255448> (a org.eclipse.pde.internal.core.PDEState)
>> at
>> org.eclipse.pde.internal.core.MinimalState.resolveState(Mini malState.java:201)
>>
>> at
>> org.eclipse.pde.internal.core.PluginModelManager.modelsChang ed(PluginModelManager.java:161)
>>
>>
>> This 30 - 45 sec lag when updating MANIFESTS is making 3.4 pretty much
>> unusable for me on fairly large projects.
>>
>> Is this a known issue? Is there anything I can tweak in my
>> configuration to prevent this?
>>
>> Thanks,
>>
>> Dave
>>
>>
|
|
|
| Re: Long delay + UI locked when saving MANIFESTs [message #594552 is a reply to message #53301] |
Thu, 02 April 2009 12:09 |
| Eclipse User |
|
|
|
Hi Stefan,
Yeah - we're using bnd to OSGI-up a whole bunch of (non OSGI) 3rd party
dependencies - and have thousands of uses constraints.
I tried the osgi.resolver.usesMode=ignore trick - and it works like a
treat!
Fortunately, we use multiple versions of the same bundle in our target
platform - so I think this will work nicely for us.
Many thanks on helping me cure an increasingly tiresome head-ache!!
Dave
|
|
|
|
| Re: Long delay + UI locked when saving MANIFESTs [message #594580 is a reply to message #53345] |
Fri, 03 April 2009 04:16 |
| Eclipse User |
|
|
|
Eric,
you're right, this is definetely not very practical but a workaround for
this problem. I hope, that this issue is addressed very soon
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=216934) to make this hack
obsolete...
Regards,
Stefan.
Eric Rizzo schrieb:
> On 4/2/2009 10:01 AM, Stefan Roeck wrote:
>> Hi Dave,
>>
>> we had the same problem and found out that the uses-constraints in our
>> target platform bundles are a problem for resolving. There are two
>> possible solutions (assuming that you don't need uses-constraints, i.e.
>> don't have multiple versions of the same bundle in your target platform):
>> - Set VM-Parameter osgi.resolver.usesMode=ignore
>> - Remove all uses-constraints from manifest files
>
> Do you mean remove them from the manifests in the target platform? That
> doesn't seem very practical given a target platform that is based on one
> of the EPP packages like "Eclipse for JEE Developers", is it?
>
> Eric
|
|
|
Powered by
FUDForum. Page generated in 0.04629 seconds
Home