It takes 3 hours to deploy WAR to WebSphere 9

2020-06-29 05:52发布

问题:

It used to take 3 minutes to deploy our WAR to WebSphere 8.5.5.0.

It takes 3 hours to deploy the same WAR to WebSphere 9.0.0.2.

Is that a manifestation of a bug in WebSphere 9.0.0.2? Did anybody have similar experience?

UPDATE: Results of my experiments with settings suggested by IBM: http://www-01.ibm.com/support/docview.wss?uid=swg21983564

Our WAR file contains 160 JAR files with total size of 160MB.

Time is measured for the "New Application" wizard, from first screen, until the next screen is shown.

  • WebSphere 8.5.5 - 3 minutes

  • WebSphere 9 - 3 hours

  • Added "Ignore-Scanning-Packages: org, net, com, javax" line to manifest file in the WAR - 30 minutes

  • Added "Enable-CDI: false" line to manifest file in the EAR - 30 minutes

  • Added lines

Enable-CDI=false

Enable-Implicit-Bean-Archive=false

to C:\Program Files\IBM\WebSphere\AppServer\properties\amm.filter.properties file - 30 minutes

  • Added JVM properties

com.ibm.ws.cdi.enableImplicitBeanArchives

false

com.ibm.ws.cdi.enableCDI

false

in Servers->Server Types->WebSphere application servers->server1->Server Infrastrucure->Java and Process Management->Process definition->Java Virtual Mashine->Custom properties - 30 minutes

  • Added JVM properties

-Dcom.ibm.ws.cdi.enableImplicitBeanArchives=false

-Dcom.ibm.ws.cdi.enableCDI=false

in Servers->Server Types->WebSphere application servers->server1->Server Infrastrucure->Java and Process Management->Process definition->Java Virtual Mashine->Generic JVM arguments - 30 minutes

UPDATE: SystemOut.log contains message:

Thread "WebContainer : ... has been active for 668644 milliseconds and may be hung.

Stack Trace contains:

at org.apache.commons.fileupload.MultipartStream.readBodyData

It looks like WebSphere is processing HTTP request to upload a file.

回答1:

A preliminary check: The application is presumed to be exactly the same for both deployments. This is more-or-less assumed, but there have been a lot of cases where the application was presumed to be the same but it wasn't, so this needs to be verified.

Between IBM WebSphere Application Server v8.5.5.0 and v9.0, a significant upgrade was made to the CDI level which is supported. That is, v9.0 adds support for CDI 1.2, which has new class and annotation scanning requirements. These new requirements, together with some problems in the initial class and scanning implementation which is used by CDI in v9.0 can cause a very large slowdown of application deployments.

The problem has been noted in particular with medium to large web modules. Here "medium to large" means web modules which have many WEB-INF/lib JAR files with a total size of 50MB or more.

In simple cases, there are two custom properties which have been added which modify the default CDI processing. See this page for information about the two properties:

http://www-01.ibm.com/support/docview.wss?uid=swg21983564

The two properties are to (1) disable CDI processing entirely; or (2) disable CDI processing for archives which do not contain a "beans.xml". See the linked page for additional details.

These two properties provide a benefit in many cases. They should be tried first, as other options are more complicated to try.