[
https://issues.redhat.com/browse/WFLY-13147?page=com.atlassian.jira.plugi...
]
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)