[JBoss JIRA] (WFLY-7385) Defining protocol of ssl config in security realm to incorrect value results in broken https
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-7385?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-7385:
-----------------------------------
Affects Version/s: 10.1.0.Final
> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-7385
> URL: https://issues.jboss.org/browse/WFLY-7385
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 10.1.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Brian Stansberry
> Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7385) Defining protocol of ssl config in security realm to incorrect value results in broken https
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-7385?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-7385:
-----------------------------------
Labels: user_experience (was: )
> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-7385
> URL: https://issues.jboss.org/browse/WFLY-7385
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 10.1.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Brian Stansberry
> Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once migrated to Remoting 5
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1897:
----------------------------------------
Summary: Follow up WFCORE-296 once migrated to Remoting 5
Key: WFCORE-1897
URL: https://issues.jboss.org/browse/WFCORE-1897
Project: WildFly Core
Issue Type: Task
Components: Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 3.0.0.Alpha11
WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-676) There isn't possible change value for given alias in Credential Store over CLI.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-676?page=com.atlassian.jira.plugin.sy... ]
Hynek Švábek updated ELY-676:
-----------------------------
Description:
There isn't possible change value for given alias in Credential Store over CLI.
I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}
Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store.
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
{code}
was:
There isn't possible change value for given alias in Credential Store over CLI.
I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}
> There isn't possible change value for given alias in Credential Store over CLI.
> -------------------------------------------------------------------------------
>
> Key: ELY-676
> URL: https://issues.jboss.org/browse/ELY-676
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.Beta10
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> There isn't possible change value for given alias in Credential Store over CLI.
> I expected something like this
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
> {code}
> Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store.
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1896) Deployment operation browse-content(archive=true) does not return archives in archived deployments
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1896?page=com.atlassian.jira.plugi... ]
Michal Jurc updated WFCORE-1896:
--------------------------------
Description:
Deployment operation browse-content(archive=true) does not return archives in archived deployments:
{code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
{
"outcome" => "success",
"result" => [
{
"path" => "jboss-kitchensink-ear-web.war",
"directory" => false,
"file-size" => 63190L
},
{
"path" => "jboss-kitchensink-ear-ejb.jar",
"directory" => false,
"file-size" => 12256L
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
"directory" => false,
"file-size" => 5582L
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
"directory" => false,
"file-size" => 143L
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
"directory" => true
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/",
"directory" => true
},
{
"path" => "META-INF/maven/",
"directory" => true
},
{
"path" => "META-INF/MANIFEST.MF",
"directory" => false,
"file-size" => 130L
},
{
"path" => "META-INF/application.xml",
"directory" => false,
"file-size" => 802L
},
{
"path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
"directory" => false,
"file-size" => 1955L
},
{
"path" => "META-INF/",
"directory" => true
}
]
}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{"outcome" => "success"}
{code}
It works correctly with exploded deployments:
{code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
{"outcome" => "success"}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
{"outcome" => "success"}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
{"outcome" => "success"}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{
"outcome" => "success",
"result" => [
{
"path" => "jboss-kitchensink-ear-web.war",
"directory" => false,
"file-size" => 63190L
},
{
"path" => "jboss-kitchensink-ear-ejb.jar",
"directory" => false,
"file-size" => 12256L
}
]
}
{code}
was:
Deployment operation browse-content(archive=true) does not return archives in archived deployments:
{code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
{
"outcome" => "success",
"result" => [
{
"path" => "jboss-kitchensink-ear-web.war",
"directory" => false,
"file-size" => 63190L
},
{
"path" => "jboss-kitchensink-ear-ejb.jar",
"directory" => false,
"file-size" => 12256L
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
"directory" => false,
"file-size" => 5582L
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
"directory" => false,
"file-size" => 143L
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
"directory" => true
},
{
"path" => "META-INF/maven/org.jboss.quickstarts.eap/",
"directory" => true
},
{
"path" => "META-INF/maven/",
"directory" => true
},
{
"path" => "META-INF/MANIFEST.MF",
"directory" => false,
"file-size" => 130L
},
{
"path" => "META-INF/application.xml",
"directory" => false,
"file-size" => 802L
},
{
"path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
"directory" => false,
"file-size" => 1955L
},
{
"path" => "META-INF/",
"directory" => true
}
]
}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{
"outcome" => "success",
"result" => [
{
"path" => "jboss-kitchensink-ear-web.war",
"directory" => false,
"file-size" => 63190L
},
{
"path" => "jboss-kitchensink-ear-ejb.jar",
"directory" => false,
"file-size" => 12256L
}
]
}
{code}
It works correctly with exploded deployments:
{code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
{"outcome" => "success"}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
{"outcome" => "success"}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
{"outcome" => "success"}
[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{
"outcome" => "success",
"result" => [
{
"path" => "jboss-kitchensink-ear-web.war",
"directory" => false,
"file-size" => 63190L
},
{
"path" => "jboss-kitchensink-ear-ejb.jar",
"directory" => false,
"file-size" => 12256L
}
]
}
{code}
> Deployment operation browse-content(archive=true) does not return archives in archived deployments
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1896
> URL: https://issues.jboss.org/browse/WFCORE-1896
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha10
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> Deployment operation browse-content(archive=true) does not return archives in archived deployments:
> {code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
> {
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
> "directory" => false,
> "file-size" => 5582L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
> "directory" => false,
> "file-size" => 143L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
> "directory" => true
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/",
> "directory" => true
> },
> {
> "path" => "META-INF/maven/",
> "directory" => true
> },
> {
> "path" => "META-INF/MANIFEST.MF",
> "directory" => false,
> "file-size" => 130L
> },
> {
> "path" => "META-INF/application.xml",
> "directory" => false,
> "file-size" => 802L
> },
> {
> "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
> "directory" => false,
> "file-size" => 1955L
> },
> {
> "path" => "META-INF/",
> "directory" => true
> }
> ]
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {"outcome" => "success"}
> {code}
> It works correctly with exploded deployments:
> {code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> }
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFCORE-1896) Deployment operation browse-content(archive=true) does not return archives in archived deployments
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1896?page=com.atlassian.jira.plugi... ]
Michal Jurc moved JBEAP-6633 to WFCORE-1896:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1896 (was: JBEAP-6633)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 3.0.0.Alpha10
(was: 7.1.0.DR6)
(was: 7.1.0.DR7)
> Deployment operation browse-content(archive=true) does not return archives in archived deployments
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1896
> URL: https://issues.jboss.org/browse/WFCORE-1896
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha10
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> Deployment operation browse-content(archive=true) does not return archives in archived deployments:
> {code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
> {
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
> "directory" => false,
> "file-size" => 5582L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
> "directory" => false,
> "file-size" => 143L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
> "directory" => true
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/",
> "directory" => true
> },
> {
> "path" => "META-INF/maven/",
> "directory" => true
> },
> {
> "path" => "META-INF/MANIFEST.MF",
> "directory" => false,
> "file-size" => 130L
> },
> {
> "path" => "META-INF/application.xml",
> "directory" => false,
> "file-size" => 802L
> },
> {
> "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
> "directory" => false,
> "file-size" => 1955L
> },
> {
> "path" => "META-INF/",
> "directory" => true
> }
> ]
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> }
> ]
> }
> {code}
> It works correctly with exploded deployments:
> {code}[standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> }
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-689) CLI - between operations REMOVE and ADD CredentialStore alias is needed reload
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-689?page=com.atlassian.jira.plugin.sy... ]
Hynek Švábek moved JBEAP-6631 to ELY-689:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-689 (was: JBEAP-6631)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Credential Store
(was: Security)
Affects Version/s: 1.1.0.Beta11
(was: 7.1.0.DR7)
> CLI - between operations REMOVE and ADD CredentialStore alias is needed reload
> ------------------------------------------------------------------------------
>
> Key: ELY-689
> URL: https://issues.jboss.org/browse/ELY-689
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.Beta11
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> If I want remove entry from credential store and immediately I try to add new entry with same alias then I get error message
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource csAlias001",
> "rolled-back" => true
> }
> {code}
> In case of reload after remove operation then adding entry with same alias passes.
> I cannot see any information about reload-required after executing remove operation.
> {code}
> {
> "outcome" => "success",
> "result" => undefined
> }
> {code}
> My suggestions
> # add there information about reload-required
> OR
> # fix it so it will not be necessary reload
> In my opinion second option is better.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7384) Removal of messaging-activemq's server stops Infinispan services
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7384:
-----------------------------------
[~pferraro] I am not sure where this issue is coming from. I don't think it's in the messaging subsystem (after I cleanly remove its resources and stop its services). But I don't know if that's an issue with the MSC or with the states of Infinispan/JGroups services. Could you have a look, please?
> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
> Key: WFLY-7384
> URL: https://issues.jboss.org/browse/WFLY-7384
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
> Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7384) Removal of messaging-activemq's server stops Infinispan services
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7384:
-----------------------------------
This issue occurs after I fixed WFLY-7333 (not merged in master branch yet)
> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
> Key: WFLY-7384
> URL: https://issues.jboss.org/browse/WFLY-7384
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
> Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months