[jbossws-issues] [JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)

[Stefan Moebius (JIRA)]

Stefan Moebius created JBWS-4080:
------------------------------------

             Summary: Unpublishing WSDL files takes very long (race condition?)
                 Key: JBWS-4080
                 URL: https://issues.jboss.org/browse/JBWS-4080
             Project: JBoss Web Services
          Issue Type: Bug
          Components: jbossws-cxf
    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.

The change:
[https://github.com/jbossws/jbossws-cxf/commit/162c9e4d44f9832de6b6147b3b9c6913164ca873]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)