[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma edited comment on JBWS-4080 at 7/5/19 12:05 AM:
-------------------------------------------------------
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
was (Author: jim.ma):
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{{
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
}}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
> 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
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> 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.12.1#712002)
7 years
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma edited comment on JBWS-4080 at 7/5/19 12:05 AM:
-------------------------------------------------------
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{code:java}
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
{code}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
was (Author: jim.ma):
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
> 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
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> 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.12.1#712002)
7 years
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma edited comment on JBWS-4080 at 7/5/19 12:04 AM:
-------------------------------------------------------
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{{
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
}}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
was (Author: jim.ma):
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{quote}
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
{quote}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
> 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
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> 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.12.1#712002)
7 years
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma edited comment on JBWS-4080 at 7/5/19 12:03 AM:
-------------------------------------------------------
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{quote}
\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd
{quote}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
was (Author: jim.ma):
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{quote}\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd{quote}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
> 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
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> 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.12.1#712002)
7 years
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on JBWS-4080:
------------------------------
[~stmoebius] I tried to reproduce this issue on windows10 without success. I didn't see there is delay to unpublish wsdl after I deployed an ear with jboss-cli.bat to shutdown widlfly 10.1.0.Final.
The generated wsdl in data directory like :
{quote}\---wsdl
\---jaxws-cxf-jbws3655.ear
\---jaxws-cxf-jbws3655-ejb.jar
Hello.wsdl
Hello_schema1.xsd{quote}
I also tried with wildfly 10.0.0.Final(jbossws-cxf-server-5.1.3.Final) and I didn't see it's fast to unpublish wsdl while shutdown wildfly.
I'll close this issue. When you get this issue again , please feel free to reopen it with more reproduce details. Thanks.
> 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
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> 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.12.1#712002)
7 years