Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Date: Thu, 28 Sep 2017 19:50:00 +0000 (UTC)
From: "Robert Varga (JIRA)" <jira@apache.org>
To: issues@karaf.apache.org
Message-ID: <JIRA.13105843.1506628104000.229548.1506628200321@Atlassian.JIRA>
In-Reply-To: <JIRA.13105843.1506628104000@Atlassian.JIRA>
References: <JIRA.13105843.1506628104000@Atlassian.JIRA> <JIRA.13105843.1506628104242@jira-lw-us.apache.org>
Subject: [jira] [Updated] (KARAF-5395)
 ResourceImpl/RequirementImpl/CapabilityImpl do not correctly implement
 their OSGi interface contracts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 28 Sep 2017 19:50:06 -0000


     [ https://issues.apache.org/jira/browse/KARAF-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Varga updated KARAF-5395:
--------------------------------
    Description: 
This is a follow-up of downstream issue tracked at https://bugs.opendaylight.org/show_bug.cgi?id=9218.

OpenDaylight uses auto-generated features, which may end up packaging a bundle multiple times in separate features -- which can be regarded as a bug, but it certainly is counter-intuitive.

Using a simple test case of wanting to install all features at the same time triggers huge memory usage spike in Felix Resolver.

Since ResourceImpl does not explictly override hashCode()/equals() according to org.osgi.resource.Resource interface contract, every resource declaration in a feature is treated as unique -- disregarding the fact that multiple bundle declarations are actually pointing to the same bundle.

This cascades to both RequirementImpl and CapabilityImpl, hence each such duplicate bundle is added to the set of Requirements to be resolved and its capabilities are added to potential candidates -- leading to Felix Resolver having a large problem space (what to resolve) and also having a large solution space (how to resolve) -- leading to polynomial explosion in CPU and memory requirements.

The amount of memory consumed by OpenDaylight Nitrogen RC3 has been observed at 1.6GB, e.g. with a heap smaller than that, the container runs into OOM during feature:install before actual installation starts.

  was:
This is a follow-up of downstream issue tracked at https://bugs.opendaylight.org/show_bug.cgi?id=9218.

OpenDaylight uses auto-generated features, which may end up packaging a bundle multiple times in separate features -- which can be regarded as a bug, but it certainly is counter-intuitive.

Using a simple test case of wanting to install all features at the same time triggers huge memory usage spike in Felix Resolver.

Since ResourceImpl does not explictly override hashCode()/equals() according to org.osgi.resource.Resource interface contract, every resource declaration in a feature is treated as unique -- disregarding the fact that multiple bundle declarations are actually pointing to the same bundle.

This cascades to both RequirementImpl and CapabilityImpl, hence each such duplicate bundle is added to the set of Requirements to be resolved and its capabilities are added to potential candidates -- leading to Felix Resolver having a large problem space (what to resolve) and also having a large solution space (how to resolve) -- leading to polynomial explosion in CPU and memory requirements.

The amount of memory consumed by OpenDaylight Nitrogen RC3 has been observed at 1.6GB, e.g. with a heap smaller than that, the container runs into OOM.


> ResourceImpl/RequirementImpl/CapabilityImpl do not correctly implement their OSGi interface contracts
> -----------------------------------------------------------------------------------------------------
>
>                 Key: KARAF-5395
>                 URL: https://issues.apache.org/jira/browse/KARAF-5395
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-feature
>    Affects Versions: 4.2.0, 4.1.2, 4.0.10
>            Reporter: Robert Varga
>            Priority: Critical
>
> This is a follow-up of downstream issue tracked at https://bugs.opendaylight.org/show_bug.cgi?id=9218.
> OpenDaylight uses auto-generated features, which may end up packaging a bundle multiple times in separate features -- which can be regarded as a bug, but it certainly is counter-intuitive.
> Using a simple test case of wanting to install all features at the same time triggers huge memory usage spike in Felix Resolver.
> Since ResourceImpl does not explictly override hashCode()/equals() according to org.osgi.resource.Resource interface contract, every resource declaration in a feature is treated as unique -- disregarding the fact that multiple bundle declarations are actually pointing to the same bundle.
> This cascades to both RequirementImpl and CapabilityImpl, hence each such duplicate bundle is added to the set of Requirements to be resolved and its capabilities are added to potential candidates -- leading to Felix Resolver having a large problem space (what to resolve) and also having a large solution space (how to resolve) -- leading to polynomial explosion in CPU and memory requirements.
> The amount of memory consumed by OpenDaylight Nitrogen RC3 has been observed at 1.6GB, e.g. with a heap smaller than that, the container runs into OOM during feature:install before actual installation starts.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)