[JBoss JIRA] (WFLY-9903) Cannot remove modcluster subsystem for the first time
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9903:
--------------------------------------
PR is up https://github.com/wildfly/wildfly/pull/10949
> Cannot remove modcluster subsystem for the first time
> -----------------------------------------------------
>
> Key: WFLY-9903
> URL: https://issues.jboss.org/browse/WFLY-9903
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 12.0.0.Beta1
> Environment: Debian stable, openjdk 8
> Reporter: Marcel Šebek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 12.0.0.Final
>
>
> Removal of modcluster subsystem first produces an error, and succeeds for the second time:
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> ",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Error in the wildfly output is
> 18:35:11,316 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 78) MODCLUSTER000002: Initiating mod_cluster shutdown
> 18:35:11,319 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("remove") failed - address: ([("subsystem" => "modcluster")]) - failure description: "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> "
> 18:35:11,321 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> For the second time, it succeeds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client occasionally hangs
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-9900:
--------------------------------
Description:
Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
In two ouf our tests, we saw a small number of clients hang at the end. The scenarios are:
[jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
[shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
No thread dump as I didn't manage to reproduce yet.
Might be related to JBEAP-12074 or JBEAP-13169.
was:
Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
In two ouf our tests, we saw a small number of clients hang and resist termination at the end. The scenarios are:
[jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
[shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
No thread dump as I didn't manage to reproduce yet.
Might be related to JBEAP-12074 or JBEAP-13169.
> EJB client occasionally hangs
> -----------------------------
>
> Key: WFLY-9900
> URL: https://issues.jboss.org/browse/WFLY-9900
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Beta1
> Reporter: Richard Janík
> Assignee: David Lloyd
> Attachments: threaddump-client.txt, threaddump-server1.txt, threaddump-server2.txt, threaddump-server3.txt, threaddump-server4.txt
>
>
> Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
> In two ouf our tests, we saw a small number of clients hang at the end. The scenarios are:
> [jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
> [shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
> The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
> No thread dump as I didn't manage to reproduce yet.
> Might be related to JBEAP-12074 or JBEAP-13169.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Alessandro Moscatelli commented on WFLY-9878:
---------------------------------------------
Here, I made a simple new empty project with a single entity and a single startup bean ...
... and it's not working :
2018-02-27 11:41:02,407 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 83) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "eclipselinktest-ear-1.0.0-SNAPSHOT.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"eclipselinktest-ear-1.0.0-SNAPSHOT.ear\".\"eclipselinktest-ejb-1.0.0-SNAPSHOT.jar\".component.TestBean.START" => "java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.TestEntity@3bc58e76 is not a known Entity type.
Caused by: java.lang.IllegalArgumentException: Object: org.visiontech.TestEntity@3bc58e76 is not a known Entity type."}}
2018-02-27 11:41:02,407 ERROR [org.jboss.as.server] (management-handler-thread - 83) WFLYSRV0021: Deploy of deployment "eclipselinktest-ear-1.0.0-SNAPSHOT.ear" was rolled back with the following failure message:
{"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"eclipselinktest-ear-1.0.0-SNAPSHOT.ear\".\"eclipselinktest-ejb-1.0.0-SNAPSHOT.jar\".component.TestBean.START" => "java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.TestEntity@3bc58e76 is not a known Entity type.
Caused by: java.lang.IllegalArgumentException: Object: org.visiontech.TestEntity@3bc58e76 is not a known Entity type."}}
[^eclipselinktest.zip]
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Attachments: eclipselinktest.zip, screenshot-1.png
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Alessandro Moscatelli updated WFLY-9878:
----------------------------------------
Attachment: eclipselinktest.zip
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Attachments: eclipselinktest.zip, screenshot-1.png
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client occasionally hangs
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Richard Janík commented on WFLY-9900:
-------------------------------------
Unfortunately no, the clients are simply stuck in awaitResponse:
{noformat}
"Runner - 565" #638 daemon prio=5 os_prio=0 tid=0x00007feb9841d000 nid=0x7f47 in Object.wait() [0x00007feaeb593000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:866)
- locked <0x00000006826573b0> (a java.lang.Object)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:177)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112)
at com.sun.proxy.$Proxy3.getSerialAndIncrement(Unknown Source)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:83)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
{noformat}
I'll attach the full client and server dumps.
> EJB client occasionally hangs
> -----------------------------
>
> Key: WFLY-9900
> URL: https://issues.jboss.org/browse/WFLY-9900
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Beta1
> Reporter: Richard Janík
> Assignee: David Lloyd
> Attachments: threaddump-client.txt, threaddump-server1.txt, threaddump-server2.txt, threaddump-server3.txt, threaddump-server4.txt
>
>
> Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
> In two ouf our tests, we saw a small number of clients hang and resist termination at the end. The scenarios are:
> [jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
> [shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
> The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
> No thread dump as I didn't manage to reproduce yet.
> Might be related to JBEAP-12074 or JBEAP-13169.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client occasionally hangs
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-9900:
--------------------------------
Attachment: threaddump-client.txt
threaddump-server1.txt
threaddump-server2.txt
threaddump-server3.txt
threaddump-server4.txt
> EJB client occasionally hangs
> -----------------------------
>
> Key: WFLY-9900
> URL: https://issues.jboss.org/browse/WFLY-9900
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Beta1
> Reporter: Richard Janík
> Assignee: David Lloyd
> Attachments: threaddump-client.txt, threaddump-server1.txt, threaddump-server2.txt, threaddump-server3.txt, threaddump-server4.txt
>
>
> Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
> In two ouf our tests, we saw a small number of clients hang and resist termination at the end. The scenarios are:
> [jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
> [shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
> The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
> No thread dump as I didn't manage to reproduce yet.
> Might be related to JBEAP-12074 or JBEAP-13169.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Alessandro Moscatelli commented on WFLY-9878:
---------------------------------------------
!screenshot-1.png|thumbnail!
Mine is a standard maven enterprise application archive (so this is an ear generated with maven project).
persistence.xml is inside META-INF folder you can see in the screenshot.
Some entities are in inside jars inside lib folder, others are inside ejb jar you can see in the root.
I made several test creating a test dummy entitiy and scanner didn't work independently from where I placed it.
For example it makes no sense this doesn't work placing it inside the EJB module.
Do you really need my piece of code ?
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Attachments: screenshot-1.png
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9903) Cannot remove modcluster subsystem for the first time
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9903:
---------------------------------
Fix Version/s: 12.0.0.Final
> Cannot remove modcluster subsystem for the first time
> -----------------------------------------------------
>
> Key: WFLY-9903
> URL: https://issues.jboss.org/browse/WFLY-9903
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 12.0.0.Beta1
> Environment: Debian stable, openjdk 8
> Reporter: Marcel Šebek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 12.0.0.Final
>
>
> Removal of modcluster subsystem first produces an error, and succeeds for the second time:
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> ",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Error in the wildfly output is
> 18:35:11,316 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 78) MODCLUSTER000002: Initiating mod_cluster shutdown
> 18:35:11,319 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("remove") failed - address: ([("subsystem" => "modcluster")]) - failure description: "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> "
> 18:35:11,321 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> For the second time, it succeeds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9903) Cannot remove modcluster subsystem for the first time
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9903:
---------------------------------
Priority: Critical (was: Major)
> Cannot remove modcluster subsystem for the first time
> -----------------------------------------------------
>
> Key: WFLY-9903
> URL: https://issues.jboss.org/browse/WFLY-9903
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 12.0.0.Beta1
> Environment: Debian stable, openjdk 8
> Reporter: Marcel Šebek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 12.0.0.Final
>
>
> Removal of modcluster subsystem first produces an error, and succeeds for the second time:
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> ",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Error in the wildfly output is
> 18:35:11,316 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 78) MODCLUSTER000002: Initiating mod_cluster shutdown
> 18:35:11,319 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("remove") failed - address: ([("subsystem" => "modcluster")]) - failure description: "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> "
> 18:35:11,321 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> For the second time, it succeeds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months