Hi JB,
We're not using the generate-features-MOJO either, the feature.xml has been
written by hand. But by using the assembly-MOJO, the
etc\org.apache.karaf.features.xml is generated, which I can also see in
the logging :
*22:43:01,512 [INFO] Generating features processor configuration:
etc\org.apache.karaf.features.xml*
I think the prefixes should be OK indeed, but it would be nice to leave
them out while looking for a solution for the other problem.
Below you can find the stacktrace from the OOM, I also have a list of
Objectsin my heapdump :
Class Name | Objects | Shallow
Heap | Retained Heap
----------------------------------------------------------------------------------------------
org.apache.felix.resolver.util.CandidateSelector| 149,133,654 |
3,579,207,696 |
org.apache.felix.resolver.util.ShadowList | 6,636,000 |
212,352,000 |
org.apache.felix.resolver.util.CopyOnWriteSet | 272,437 |
4,358,992 |
org.apache.felix.resolver.ResolverImpl$Blame | 87,915 |
2,109,960 |
org.apache.felix.resolver.util.OpenHashMapSet | 18,261 |
1,460,880 |
org.apache.felix.resolver.util.OpenHashMapList | 17,697 |
1,415,760 |
org.apache.felix.utils.resource.SimpleFilter | 41,589 |
998,136 |
org.apache.felix.resolver.Candidates | 17,697 |
849,456 |
----------------------------------------------------------------------------------------------
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid12712.hprof ...
Heap dump file created [14183481728 bytes in 193.147 secs]
java.lang.OutOfMemoryError: Java heap space
at
org.apache.felix.resolver.util.OpenHashMap.clone(OpenHashMap.java:820)
at
org.apache.felix.resolver.util.OpenHashMapList.deepClone(OpenHashMapList.java:35)
at org.apache.felix.resolver.Candidates.copy(Candidates.java:1143)
at
org.apache.felix.resolver.ResolverImpl.permuteUsedBlames(ResolverImpl.java:1598)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1464)
at
org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:621)
at
org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:574)
at
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:437)
at
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:420)
at
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:374)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:478)
at org.apache.felix.framework.Felix.resolveBundles(Felix.java:4327)
at
org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:133)
at
org.apache.karaf.features.internal.service.BundleInstallSupportImpl.resolveBundles(BundleInstallSupportImpl.java:244)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.resolveBundles(FeaturesServiceImpl.java:1175)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1027)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl$$Lambda$220/0x00000007c0479c40.call(Unknown
Source)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
2021-11-28 09:53:02,366 -
[o.a.k.f.i.s.BootFeaturesInstaller][activator-1-thread-2] ERROR - Error
installing boot features
java.lang.OutOfMemoryError: Java heap space
at
org.apache.felix.resolver.util.OpenHashMap.clone(OpenHashMap.java:820)
at
org.apache.felix.resolver.util.OpenHashMapList.deepClone(OpenHashMapList.java:35)
at org.apache.felix.resolver.Candidates.copy(Candidates.java:1143)
at
org.apache.felix.resolver.ResolverImpl.permuteUsedBlames(ResolverImpl.java:1598)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1464)
at
org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:621)
at
org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:574)
at
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:437)
at
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:420)
at
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:374)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:478)
at org.apache.felix.framework.Felix.resolveBundles(Felix.java:4327)
at
org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:133)
at
org.apache.karaf.features.internal.service.BundleInstallSupportImpl.resolveBundles(BundleInstallSupportImpl.java:244)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.resolveBundles(FeaturesServiceImpl.java:1175)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1027)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl$$Lambda$220/0x00000007c0479c40.call(Unknown
Source)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Kind regards,
Steven
On Sun, Nov 28, 2021 at 8:17 AM Jean-Baptiste Onofre <j...@nanthrax.net>
wrote:
> Hi Steven,
>
> Let me try to reproduce on a simple test case.
>
> I don’t see yet the relationship between the prefixes generated (which are
> not bad IMHO) and the OOM (I’m suspecting more like a loop in the features
> XML definition).
>
> Just a reminder: in Karaf itself, we don’t use the generate-features MOJO,
> we write the features XML/JSON by hand (largely better to have a complete
> control).
>
> Regards
> JB
>
> > Le 27 nov. 2021 à 22:15, Steven Huypens <steven.huyp...@gmail.com> a
> écrit :
> >
> > Hi Bernd,
> >
> > That's what I did :
> >
> > 1) Compile all code with Java 8, create distro with Java 8, run with
> Java 8
> > --> Works
> > 2) Compile all code with Java 8, create distro with Java 8, run with Java
> > 11 --> Works
> > 3) Compile all code with Java 8, create distro with Java 11, run with
> Java
> > 11 --> Doesn't work, app goes OOM
> > 4) Compile all code with Java 11, create distro with Java 11, run with
> Java
> > 11 --> Doesn't work, app goes OOM
> >
> > The only difference between (2) and (3) is the prefix in
> > org.apache.karaf.features.xml, and if I remove that manually, the app
> works
> > as expected. I also think the generated org.apache.karaf.features.xml is
> > OK, but I have no clue why the application goes OOM with it.
> >
> > Kind regards,
> > Steven
> >
> >
> >
> >
> >
> > On Sat, Nov 27, 2021 at 10:02 PM Bernd Eckenfels <e...@zusammenkunft.net
> >
> > wrote:
> >
> >> Yes looked in the wrong Schema. I think, don’t worry about the prefixes,
> >> as long as the elements are correctly qualified (the processing
> elements in
> >> your case with ns3:) they are equivalent. Your memory problems have
> likely
> >> another cause. But as stated, it might be a good idea to list the repos
> and
> >> features in both running instances and compare them, just to be sure.
> >>
> >> (Besides the maven plugin probably should define a few fixed prefixes to
> >> make it better readable)
> >>
> >> Not sure why the maven plug-in is so sensitive to the jaxb version (if
> >> executed with java11 it needs to provide its own). Can you maybe run
> both
> >> builds with the same JDK?
> >>
> >> Gruss
> >> Bernd
> >> --
> >> http://bernd.eckenfels.net
> >> ________________________________
> >> Von: Steven Huypens <steven.huyp...@gmail.com>
> >> Gesendet: Saturday, November 27, 2021 9:56:04 PM
> >> An: dev@karaf.apache.org <dev@karaf.apache.org>
> >> Betreff: Re: karaf-maven-plugin generates another
> >> org.apache.karaf.features.xml with Java 8/Java 11
> >>
> >> Hi Bernd,
> >>
> >> - I do see 'blacklistedRepositories' in
> >> http://karaf.apache.org/xmlns/features-processing/v1.0.0
> >> - With the namespace-prefix my app goes OOM immediately, so I cannot
> >> compare both running systems.
> >> - I tried adding the prefix to each child, but that did not help
> >>
> >> Kind regards,
> >> Steven
> >>
> >> On Sat, Nov 27, 2021 at 9:23 PM Bernd Eckenfels <e...@zusammenkunft.net
> >
> >> wrote:
> >>
> >>> In that case maybe the child (deny* list?) is ignored, not sure how
> >> strict
> >>> the parser is in regards to namespaces. I don’t see a
> blacklistRepository
> >>> element in the Schema anyway. It’s maybe best you inspect the running
> >>> systems with feature:* commands and look for differences.
> >>>
> >>>
> >>>
> >>> --
> >>> http://bernd.eckenfels.net
> >>> ________________________________
> >>> Von: Steven Huypens <steven.huyp...@gmail.com>
> >>> Gesendet: Saturday, November 27, 2021 8:58:20 PM
> >>> An: dev@karaf.apache.org <dev@karaf.apache.org>
> >>> Betreff: Re: karaf-maven-plugin generates another
> >>> org.apache.karaf.features.xml with Java 8/Java 11
> >>>
> >>> Hi Bernd,
> >>>
> >>> Thanks for your response. The child elements have no prefix, eg.
> >>> <blacklistedRepositories></blacklistedRepositories>
> >>>
> >>> I'm sorry but I do not understand what you mean. You think part of my
> >>> org.apache.karaf.features.xml was previously ignored ? I haven't double
> >>> checked, but that would really surprise me because we have quite some
> >>> blacklistedFeatures en blacklistedBundles which would cause problems if
> >>> ignored.
> >>>
> >>> Best regards,
> >>> Steven
> >>>
> >>> On Sat, Nov 27, 2021 at 8:22 PM Bernd Eckenfels <
> e...@zusammenkunft.net>
> >>> wrote:
> >>>
> >>>> Hello Steven
> >>>>
> >>>> How do the child elements of that element look like? Are they using
> >>>> default/f/ns2 prefix and maybe the (semantically equivalent) change
> >>> affects
> >>>> your memory only because the old form ignored a actual entry for
> >>> dependency?
> >>>>
> >>>> Bernd
> >>>>
> >>>> --
> >>>> http://bernd.eckenfels.net
> >>>> ________________________________
> >>>> Von: Romain Manni-Bucau <rmannibu...@gmail.com>
> >>>> Gesendet: Samstag, November 27, 2021 8:14 PM
> >>>> An: dev
> >>>> Betreff: Re: karaf-maven-plugin generates another
> >>>> org.apache.karaf.features.xml with Java 8/Java 11
> >>>>
> >>>> Hi Steven,
> >>>>
> >>>>
> >>>> Maybe force jaxb version to an earlier one in karag pluhin
> dependencies
> >>> in
> >>>> your pom.
> >>>>
> >>>>
> >>>> Le sam. 27 nov. 2021 à 20:05, Steven Huypens <
> steven.huyp...@gmail.com
> >>>
> >>> a
> >>>> écrit :
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I tried to create my custom Karaf distribution (using
> >>> karaf-maven-plugin
> >>>>> 4.3.2) with Java 11 for the first time, and I noticed a difference in
> >>> the
> >>>>> resulting org.apache.karaf.features.xml
> >>>>>
> >>>>> The line
> >>>>>
> >>>>> <featuresProcessing xmlns="
> >>>>> http://karaf.apache.org/xmlns/features-processing/v1.0.0"; xmlns:f="
> >>>>> http://karaf.apache.org/xmlns/features/v1.6.0";>
> >>>>>
> >>>>> has been changed into
> >>>>>
> >>>>> <ns3:featuresProcessing xmlns:ns2="
> >>>>> http://karaf.apache.org/xmlns/features/v1.6.0"; xmlns:ns3="
> >>>>> http://karaf.apache.org/xmlns/features-processing/v1.0.0";>
> >>>>>
> >>>>> which means a namespace has been added. Unfortunately this little
> >>> change
> >>>>> has a big impact because now my app immediately runs OutOfMemory
> >> when I
> >>>>> start Karaf. There is very little DEBUG-logging, the behaviour is
> >>>> somewhat
> >>>>> like described in https://issues.apache.org/jira/browse/KARAF-6068
> >>>>>
> >>>>> Removing the namespace fixes the problem.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Do you have any idea how I can prevent my app from going OOM after
> >> this
> >>>>> change ? Or how I can prevent the namespace from being added with
> >> Java
> >>>> 11 ?
> >>>>> It would be nice to understand the exact problem here.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Kind regards,
> >>>>> Steven
> >>>>>
> >>>>
> >>>
> >>
>
>
