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

[Christoph Winter (Jira)]

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

Christoph Winter commented on WFLY-13147:
-----------------------------------------

Hi [~manovotn], unfortunately we developed the application for our customer (hence proprietary) so we are not allowed to share it. Since the VisualVM Sampler does not allow to filter/remove the proprietary classes within exported Snapshots I can only provide screenshots of the identified classes showing the overall wall time.

The main issue with the ExternalBeanArchiveProcessor is that (since almost every deployment unit *u* depends on all all other modules *m* every dependency is processed multiple times.

!Screenshot from 2020-02-24 16-24-32.png|thumbnail!  !Screenshot from 2020-02-24 16-23-53.png|thumbnail! 

KR Christoph 

> 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)