You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Jean-Baptiste Onofré (Jira)" <ji...@apache.org> on 2021/03/17 08:48:00 UTC

[jira] [Commented] (KARAF-7074) Resolver parallelism can fail on kubernetes as the resolverParallelism is not accurate

    [ https://issues.apache.org/jira/browse/KARAF-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303197#comment-17303197 ] 

Jean-Baptiste Onofré commented on KARAF-7074:
---------------------------------------------

A workaround on kubernetes is to use:
{code:java}
<resolverParallelism>2</resolverParallelism> {code}

> Resolver parallelism can fail on kubernetes as the resolverParallelism is not accurate
> --------------------------------------------------------------------------------------
>
>                 Key: KARAF-7074
>                 URL: https://issues.apache.org/jira/browse/KARAF-7074
>             Project: Karaf
>          Issue Type: Dependency upgrade
>          Components: karaf
>            Reporter: Jean-Baptiste Onofré
>            Assignee: Jean-Baptiste Onofré
>            Priority: Major
>
> When building Karaf on kubernetes (on a pod), the {{resolverParallelism}} can be "bad" depending of the number of vCPU and the features dependencies.
> The {{resolverParallelism}} is computed like this:
> {code:java}
> int resolverParallelism = Math.max(1, Runtime.getRuntime().availableProcessors()); {code}
> Actually, if the features are not really sequential (features dependencies), the resolution will fail with 1 (if we have a single vCPU). The default should be at least 2.
> It's better to use {{-1}} by default and then using resolver with default parallelism, and let the user defines the {{resolverParallelism}} by parameter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)