[
https://issues.apache.org/jira/browse/FELIX-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-4926:
-----------------------------------
Description:
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.
was:
The resolver algorithm 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.
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.
> 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
>
> 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)
