[jboss-jira] [JBoss JIRA] (WFLY-13147) Deployment slowdown after WFLY upgrade (DeploymentArchive handling)

[Matěj Novotný (Jira)]

    [ https://issues.redhat.com/browse/WFLY-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000703#comment-14000703 ] 

Matěj Novotný commented on WFLY-13147:
--------------------------------------

I have sent the suggested changes as a draft PR - https://github.com/wildfly/wildfly/pull/13121
I would like to hear Brian's thoughts on this and see if WFLY has some perf tests that could measure the impact of this. Or perhaps some more corner case tests that would uncover some problems? Either way, it's up to gather other people thoughts.

> Deployment slowdown after WFLY upgrade (DeploymentArchive handling)
> -------------------------------------------------------------------
>
>                 Key: WFLY-13147
>                 URL: https://issues.redhat.com/browse/WFLY-13147
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 17.0.1.Final
>            Reporter: Christoph Winter
>            Assignee: Matěj Novotný
>            Priority: Major
>         Attachments: Screenshot from 2020-02-24 16-23-53.png, Screenshot from 2020-02-24 16-24-32.png
>
>
> Our team upgraded our application (>205 modules) from WFLY 8.2.1 to WFLY 17.0.1 we experienced a noticeable slowdown during the deployment process (3min vs. 6min)
> A colleague found out that the following classes seem to cause the lag during dependency resolution since dependencies are processed multiple times:
> * weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> * weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> and came up with the following workarounds that should fix the issues
> {noformat}
> diff --git a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> index 521f47cc7d..1b4d7e8b4c 100644
> --- a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> +++ b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java
> @@ -246,7 +246,12 @@ public class BeanDeploymentArchiveImpl implements WildFlyBeanDeploymentArchive {
> if (moduleDependency.getIdentifier().equals(that.getModule().getIdentifier())) {
> return true;
> }
> + }
> + }
> + for (DependencySpec dependency : module.getDependencies()) {
> + if (dependency instanceof ModuleDependencySpec) {
> + ModuleDependencySpec moduleDependency = (ModuleDependencySpec) dependency;
> // moduleDependency might be an alias - try to load it to get lined module
> Module module = loadModule(moduleDependency);
> if (module != null && module.getIdentifier().equals(that.getModule().getIdentifier())) {
> {noformat}
> as well as
> {noformat}
> diff --git a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> index da6e0bfcaf..1b539bba4e 100644
> --- a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> +++ b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java
> @@ -162,6 +162,12 @@ public class ExternalBeanArchiveProcessor implements DeploymentUnitProcessor {
> return;
> }
> for (DependencySpec dep : module.getDependencies()) {
> + if (!(dep instanceof ModuleDependencySpec)) {
> + continue;
> + }
> + if (deploymentUnits.stream().anyMatch(d -> (((ModuleDependencySpec)dep).getName()).endsWith(d.getName()))) {
> + continue;
> + }
> final Module dependency = loadModuleDependency(dep);
> if (dependency == null) {
> continue;{noformat}
> The fixes should prevent dependencies from being processed multiple times, however, the latter should be improved.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)