OOME when running a bndtools JUnit test, I think because of bundle resolution

[Dan Gravell <da...@elstensoftware.com>]

I'm getting an OOME when running a bndtools JUnit test. The reason I'm
posting about it here is because I think this relates to Felix's bundle
resolvers.

Even if I run the test with -Xmx512M I am getting the OOME, which is
manifest as a "GC overhead limit exceeded". This, despite running a super
set of bundles with -Xmx128M using the bndtools runner and also, at
deployment time, simply deployed within Felix. So I am trying to work out
what's going on...

Here's the stack trace that's printed:

! Unexpected error in the run body: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.ArrayList.iterator(ArrayList.java:737)
at
org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:871)
at
org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:913)
at
org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:913)
at
org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:679)
at
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:183)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:403)
at org.apache.felix.framework.Felix.resolveBundles(Felix.java:3931)
at
org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:123)
at
org.apache.felix.framework.PackageAdminImpl.resolveBundles(PackageAdminImpl.java:263)
at aQute.launcher.Launcher.update(Launcher.java:296)
at aQute.launcher.Launcher.activate(Launcher.java:241)
at aQute.launcher.Launcher.run(Launcher.java:145)
at aQute.launcher.Launcher.main(Launcher.java:80)

I can provide the HPROF and the bundles, although the HPROF is 146MB and
wanted to avoid using up my monthly bandwidth allowance. It will also take
a good hour and a half to upload I think. It shows a ResolverImpl consuming
413MB with 3442 Candidates objects in its m_usesPermutations list.

Let me know what I can provide to help with this.

I'm guessing there's something kooky about my bundles, but it seems strange
given they work in other scenarios.

Dan

Re: OOME when running a bndtools JUnit test, I think because of bundle resolution

[Dan Gravell <da...@elstensoftware.com>]

Ok, I think I found the cause. I have both a system bundle fragment
exporting some packages, AND:

-runsystempackages: sun.misc,sun.nio,sun.nio.ch
,sun.reflect,junit.framework,javax.servlet,javax.servlet.http,sun.reflect

... in my bndrun file. I removed the latter, and now it appears to start
without issue.

Dan


On Fri, Jun 14, 2013 at 4:16 PM, Dan Gravell <da...@elstensoftware.com> wrote:

> I'm getting an OOME when running a bndtools JUnit test. The reason I'm
> posting about it here is because I think this relates to Felix's bundle
> resolvers.
>
> Even if I run the test with -Xmx512M I am getting the OOME, which is
> manifest as a "GC overhead limit exceeded". This, despite running a super
> set of bundles with -Xmx128M using the bndtools runner and also, at
> deployment time, simply deployed within Felix. So I am trying to work out
> what's going on...
>
> Here's the stack trace that's printed:
>
> ! Unexpected error in the run body: GC overhead limit exceeded
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:737)
>  at
> org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:871)
> at
> org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:913)
>  at
> org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:913)
> at
> org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:679)
>  at
> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:183)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:403)
>  at org.apache.felix.framework.Felix.resolveBundles(Felix.java:3931)
> at
> org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:123)
>  at
> org.apache.felix.framework.PackageAdminImpl.resolveBundles(PackageAdminImpl.java:263)
> at aQute.launcher.Launcher.update(Launcher.java:296)
>  at aQute.launcher.Launcher.activate(Launcher.java:241)
> at aQute.launcher.Launcher.run(Launcher.java:145)
>  at aQute.launcher.Launcher.main(Launcher.java:80)
>
> I can provide the HPROF and the bundles, although the HPROF is 146MB and
> wanted to avoid using up my monthly bandwidth allowance. It will also take
> a good hour and a half to upload I think. It shows a ResolverImpl consuming
> 413MB with 3442 Candidates objects in its m_usesPermutations list.
>
> Let me know what I can provide to help with this.
>
> I'm guessing there's something kooky about my bundles, but it seems
> strange given they work in other scenarios.
>
> Dan
>
>
>