Stefan Moebius created JBWS-4080:
Summary: Unpublishing WSDL files takes very long (race condition?)
Project: JBoss Web Services
Issue Type: Bug
Affects Versions: jbossws-cxf-5.1.9.Final, jbossws-cxf-5.1.8.Final,
jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.5.Final
Environment: Windows, Java 8, Wildfly 10.1
Reporter: Stefan Moebius
The change done for [https://issues.jboss.org/browse/JBWS-3992
] causes shutdown of Wildfly
10.1 to take much longer, causing timeouts in the Windows service manager.
The problem appears to be this:
There is a pool of “MSC service threads”. These threads are responsible among other things
for the publishing and also the unpublishing of web services, which involves the creation
and also the deletion of WSDL files, using WSDLFilePublisher. These threads operate on
deployment units, which means the JARs inside an EAR.
The WSDL files are published in this structure:
data/wsdl/Bar.ear/<Foo>.jar/, with one folder for each JAR that has WS.
In jbossws-cxf-5.1.4, each of these threads would delete the files and the folder for one
deployment unit, i.e. one JAR. The impact was that the root folder data/wsdl/Bar.ear/
would remain, which was reported as a JBWS-3992 and fixed in 5.1.5.
The fixed, however, causes each thread to now traverse to the root deployment unit
(Bar.ear) and recursively delete all files under data/wsdl/Bar.ear and the folder itself.
The problem is that this causes multiple threads to attempt to delete the same tree of
files in parallel, at least on Windows causing this to take ages.
This message was sent by Atlassian JIRA