Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Fri, 26 Jun 2015 12:32:04 +0000 (UTC)
From: "Guillaume Nodet (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12837432.1434121372000.25718.1435321924523@Atlassian.JIRA>
In-Reply-To: <JIRA.12837432.1434121372000@Atlassian.JIRA>
References: <JIRA.12837432.1434121372000@Atlassian.JIRA>
 <JIRA.12837432.1434121372948@arcas>
Subject: [jira] [Assigned] (FELIX-4926) Investigate rewriting the resolver
 algorithm to use loops instead of recursion
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Guillaume Nodet reassigned FELIX-4926:
--------------------------------------

    Assignee: Guillaume Nodet

> Investigate rewriting the resolver algorithm to use loops instead of recursion 
> -------------------------------------------------------------------------------
>
>                 Key: FELIX-4926
>                 URL: https://issues.apache.org/jira/browse/FELIX-4926
>             Project: Felix
>          Issue Type: New Feature
>          Components: Resolver
>            Reporter: Guillaume Nodet
>            Assignee: Guillaume Nodet
>
> The resolver algorithm for {{Candidates#populate}} currently uses a recursive algorithm.
> At first glance, the number of recursion can amount to the number of resources to resolve.  This limits the size of the resolution.
> I'd like to investigate replacing the recursion with a loop.  
> This may also allow using a fork/join design to leverage multiple cores for the resolution.  The fork/join could also be used for the main resolution loop.
> It may make things slightly harder to keep the reproducibility of the algorithm if things are not always considered in the same order.  Though there may be some way around.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)