[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
R Searls updated JBWS-4080:
---------------------------
Assignee: R Searls
> 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.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final
> Environment: Windows, Java 8, Wildfly 10.1
> Reporter: Stefan Moebius
> Assignee: R Searls
> Fix For: jbossws-cxf-5.2.0.Final
>
>
> The change done for 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/162c9e4d44f9832de6b6147b3b9...]
> As a workaround, we've downgraded to 5.1.4, which made the issue go away.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JBWS-4035) BusHolder uses deprecated register() from InstrumentationManagerImpl
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4035?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4035:
----------------------------------
Assignee: Viral Gohel (was: Alessio Soldano)
> BusHolder uses deprecated register() from InstrumentationManagerImpl
> --------------------------------------------------------------------
>
> Key: JBWS-4035
> URL: https://issues.jboss.org/browse/JBWS-4035
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Reporter: Rostislav Svoboda
> Assignee: Viral Gohel
>
> Running {{mvn -fn clean install -Dmaven.test.skip=true -Dmaven.compiler.showDeprecation=true}} against jbossws-cxf code reports 1 deprecation:
> {code}
> /home/rsvoboda/git/jbossws-cxf/modules/server/src/main/java/org/jboss/wsf/stack/
> cxf/configuration/BusHolder.java:[437,38] [deprecation] register() in
> InstrumentationManagerImpl has been deprecated
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4080:
----------------------------------
Fix Version/s: jbossws-cxf-5.2.0.Final
> 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.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final
> Environment: Windows, Java 8, Wildfly 10.1
> Reporter: Stefan Moebius
> Fix For: jbossws-cxf-5.2.0.Final
>
>
> The change done for 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/162c9e4d44f9832de6b6147b3b9...]
> As a workaround, we've downgraded to 5.1.4, which made the issue go away.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Stefan Moebius (JIRA)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Stefan Moebius updated JBWS-4080:
---------------------------------
Description:
The change done for 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/162c9e4d44f9832de6b6147b3b9...]
As a workaround, we've downgraded to 5.1.4, which made the issue go away.
was:
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/162c9e4d44f9832de6b6147b3b9...]
> 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.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final
> Environment: Windows, Java 8, Wildfly 10.1
> Reporter: Stefan Moebius
>
> The change done for 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/162c9e4d44f9832de6b6147b3b9...]
> As a workaround, we've downgraded to 5.1.4, which made the issue go away.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by 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/162c9e4d44f9832de6b6147b3b9...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JBWS-4079) Extend web service subsystem to configure cxf.management properties outside endpoint-config
by Viral Gohel (JIRA)
Viral Gohel created JBWS-4079:
---------------------------------
Summary: Extend web service subsystem to configure cxf.management properties outside endpoint-config
Key: JBWS-4079
URL: https://issues.jboss.org/browse/JBWS-4079
Project: JBoss Web Services
Issue Type: Feature Request
Components: jbossws-cxf
Affects Versions: jbossws-cxf-5.2.0.Final
Reporter: Viral Gohel
Presently for configuring the cxf.management properties, we can do this using jboss-webservice.xml file, https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... as these properties are read at the deployment time.
Since, the cxf.management properties are set at Bus level, we can look to extend those properties to be configured outside the endpoint-config and client-config. We can look to have a central configuration for this in the standalone.xml file as the below:
{code:java}
<subsystem xmlns="urn:jboss:domain:webservices:1.2">
<modify-wsdl-address>true</modify-wsdl-address>
<wsdl-host>jbossws.undefined.host</wsdl-host>
<endpoint-config name="Standard-Endpoint-Config">
<property name="cxf.management.enabled" value="true"/>
<property name="cxf.management.installResponseTimeInterceptors" value="true"/>
<property name="cxf.features" value="org.apache.cxf.management.interceptor.ResponseTimeFeature"/>
</endpoint-config>
<endpoint-config name="Recording-Endpoint-Config">
<pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
<handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
</pre-handler-chain>
</endpoint-config>
<client-config name="Standard-Client-Config">
<property name="cxf.management.enabled" value="true"/>
<property name="cxf.management.installResponseTimeInterceptors" value="true"/>
<property name="cxf.features" value="org.apache.cxf.management.interceptor.ResponseTimeFeature"/>
</client-config>
</subsystem>
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JBWS-4078) Allow configuration of CXF fault interceptors as JBossWS properties
by Markus Lindström (JIRA)
Markus Lindström created JBWS-4078:
--------------------------------------
Summary: Allow configuration of CXF fault interceptors as JBossWS properties
Key: JBWS-4078
URL: https://issues.jboss.org/browse/JBWS-4078
Project: JBoss Web Services
Issue Type: Feature Request
Components: jbossws-cxf
Affects Versions: jbossws-cxf-5.1.9.Final
Reporter: Markus Lindström
Proposed solution for the JBWS-4077 feature enhancement, including adapted unit tests.
The purpose of this enhancement is to introduce two new properties into the JBossWS configuration, "cxf.interceptors.infault" and "cxf.interceptors.outfault", that allow services to register InFault and OutFault interceptors respectively, in the same vein as the existing "cxf.interceptors.in" and "cxf.interceptors.out" properties for In and Out interceptors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month