[JBoss JIRA] (WFLY-7332) Infinispan transformation tests fail on backups resource for EAP 7.0.0
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7332?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-7332:
--------------------------------------
I wonder if this wasn't introduced as side effect of https://github.com/wildfly/wildfly/pull/8432
> Infinispan transformation tests fail on backups resource for EAP 7.0.0
> ----------------------------------------------------------------------
>
> Key: WFLY-7332
> URL: https://issues.jboss.org/browse/WFLY-7332
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> {noformat}
> Failed tests:
> TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
> "expiration" => {
> "interval" => 10000L,
> "lifespan" => 10L,
> "max-idle" => 10L
> },
> "state-transfer" => {
> "chunk-size" => 10000,
> "enabled" => undefined,
> "timeout" => 60000L
> },
> "eviction" => {
> "max-entries" => 20000L,
> "strategy" => "UNORDERED"
> },
> "locking" => {
> "acquire-timeout" => 30000L,
> "concurrency-level" => 2000,
> "isolation" => "READ_COMMITTED",
> "striping" => true
> },
> "backups" => {},
> "transaction" => {
> "locking" => "OPTIMISTIC",
> "mode" => "FULL_XA",
> "stop-timeout" => 60000L
> },
> "backup-for" => {},
> "partition-handling" => {}
> }
> {
> "expiration" => {
> "max-idle" => 10L,
> "lifespan" => 10L,
> "interval" => 10000L
> },
> "state-transfer" => {
> "chunk-size" => 10000,
> "timeout" => 60000L,
> "enabled" => undefined
> },
> "eviction" => {
> "max-entries" => 20000L,
> "strategy" => "UNORDERED"
> },
> "locking" => {
> "striping" => true,
> "isolation" => "READ_COMMITTED",
> "acquire-timeout" => 30000L,
> "concurrency-level" => 2000
> },
> "backups" => undefined,
> "transaction" => {
> "mode" => "FULL_XA",
> "locking" => "OPTIMISTIC",
> "stop-timeout" => 60000L
> },
> "backup-for" => {},
> "partition-handling" => {}
> } expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>
> Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-1672) Shared memory to send message between different processes on the same box
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1672?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1672:
--------------------------------
Any design of shared memory for exchanging must be faster than using an multicast (UDP) or N-1 unicasts (TCP). If this is not the case, we can scrap this issue.
Here's a possible design:
* Each sender (producer) sends a message that's to be received by all receivers (consumers) in the same cluster on the same box
* MPMC (multiple producers multiple consumers)
* Use a memory mapped file (or a direct ByteBuffer). I don't want to use Unsafe at this point, I'd rather wait and see what the replacement to it will be.
* A ring buffer is implemented in shared memory.
* There's a write pointer (WP) and a read pointer (RP)
* Producers advance the WP
* Consumers (essentially processes in the same cluster on the same box) register by adding their own TRP (thread read pointer) to shared memory (location TBD)
* A consumer reads messages by advancing their TRP until they hit the WP
* We know what the highest value for the RP will be by taking the min of all TRPs
* The RP is advanced as follows:
** The first writer to hit the RP advances the RP by setting it to the min of all TRPs
h4. Exclusive access and visibility
Producers need to make sure only one at a time advances the WP/RP and read/write from/to those values needs proper visibility, so other producers / consumers see the changes. Investigate if volatile read/writes can be used.
Investigate if \[1\] can be used as an MPSC queue.
\[1\] http://psy-lob-saw.blogspot.ch/
> Shared memory to send message between different processes on the same box
> -------------------------------------------------------------------------
>
> Key: JGRP-1672
> URL: https://issues.jboss.org/browse/JGRP-1672
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: ShmTest.java
>
>
> Investigate whether it makes sense to use shared memory to pass messages between processes on the same box. Say if we have A, B and C on box-1 and X, Y, Z on box-2, when A multicasts a message, it could loop it back to itself, place it into shared memory for B and C to read and multicast it to X, Y, Z. The multicast socket could be non-loopback, so box-1 would not receive it.
> Problems:
> * Shared memory in Java can only be done via memory mapped (sequential or random access) files. To pass a lot of messages, something like a ring buffer would have to be created in shared memory
> * Unless we use FileLock, or polling/busy reading, there is no way to know when a producer has written a message into shared memory. We'd therefore have to use a signalling mechanism, probably a small JGroups message, to notify the consumer(s) of new messages.
> ** Alternatively, we could do busy waiting: the producer writes into a memory location when a message is ready to be consumed. Perhaps this memory location can be the number of messages ready to be read. The consumer could busy-wait, and decrement the number of messages read. This variable could be protected by a file lock, so after some amount of busy-waiting, the consumer could go back and do a real wait on the file lock, instead of burning CPU doing busy-waits.
> * For multicast messages, we'd have 1 producer but many consumers. A RingBuffer would not work here, as we don't know when all consumers have read a given message, ie. when to advance the read pointer
> ** As an alternative, we could have one shared memory buffer per member on the same host. This would also cater to unicast messages. However, then we'd use up a lot of memory.
> * How would this work for TCP ? We'd have to send the message to only members which are outside the local box. How do we identify those members ?
> * Message reception: a multicast message received and targetted to all members on the same box could also be placed into shared memory, so everyone on the same box receives it
> ** How would this work for TCP ? E.g. A sending a multicast message M would use shared memory to deliver M to B and C on box-1, but if it sends it to X, Y and Z, then that's unneeded work, as it could send it only to X, which could place it into shared memory for Y and Z to consume M.
> *** We'd have to include the knowledge of 'affinity' into an address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7334) Elytron kerberos implementation ignore java.security.krb5.* system properties
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6476 to WFLY-7334:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7334 (was: JBEAP-6476)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR6)
> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-7334
> URL: https://issues.jboss.org/browse/WFLY-7334
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Critical
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code}
> -Djava.security.krb5.conf=/unreal/path -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
> <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
> <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
> <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
> <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1334) Kie service client should not allow null parameters
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1334?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1334:
-------------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> Kie service client should not allow null parameters
> ---------------------------------------------------
>
> Key: DROOLS-1334
> URL: https://issues.jboss.org/browse/DROOLS-1334
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.Final
> Reporter: Slavomir Krupa
> Assignee: Maciej Swiderski
>
> This issue occurs when you are using a kie-server-client and want to query i.e.
> {code:java}
> List<TaskSummary> findTasksByStatusByProcessInstanceId(Long processInstanceId, List<String> status, Integer page, Integer pageSize);
> {code}
> If you don't provide a processInstanceId it creates this URL:
> {noformat}
> http://localhost:8080/kie-server/services/rest/server/queries/tasks/insta...
> {noformat}
> Result is a exception on the server, but I think it should be validated in a client and should not even query the server:
> {noformat}
> ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (http-127.0.0.1:8080-6) RESTEASY000100: Failed executing GET server/queries/tasks/instances/process/{pInstanceId}: org.jboss.resteasy.spi.BadRequestException: RESTEASY001720: Unable to extract parameter from http request: javax.ws.rs.PathParam("pInstanceId") value is {1} for public javax.ws.rs.core.Response org.kie.server.remote.rest.jbpm.RuntimeDataResource.getTasksByStatusByProcessInstanceId(javax.ws.rs.core.HttpHeaders,java.lang.Long,java.util.List,java.lang.Integer,java.lang.Integer,java.lang.String,boolean)
> at org.jboss.resteasy.core.StringParameterInjector.extractValue(StringParameterInjector.java:310) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.PathParamInjector.inject(PathParamInjector.java:117) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:137) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:160) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:560) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.10.Final-redhat-2.jar:7.5.10.Final-redhat-2]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedConstructorAccessor154.newInstance(Unknown Source) [:1.8.0_65]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_65]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_65]
> at org.jboss.resteasy.core.StringParameterInjector.extractValue(StringParameterInjector.java:298) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> ... 28 more
> Caused by: java.lang.NumberFormatException: For input string: "{pInstanceId}"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_65]
> at java.lang.Long.parseLong(Long.java:589) [rt.jar:1.8.0_65]
> at java.lang.Long.<init>(Long.java:965) [rt.jar:1.8.0_65]
> ... 32 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman edited comment on WFLY-5213 at 10/18/16 8:34 AM:
---------------------------------------------------------------
I checked your client and its fine, on MDB site you have to use @ResourceAdapter(value="remote-artemis")just above "public class MessageConsiumer implements MessageListener ". I think you can safely remove "connectionFactoryLookup"
If you want to use remote broker in all MDBs by default, change "resource-adapter-name" attribute in EJB3 subsystem in your standalone-full.xml
was (Author: okalman):
I checked your client and its fine, on MDB site you have to use @ResourceAdapter(value="remote-artemis")just above "public class MessageConsiumer implements MessageListener ". I think you can safely remove "connectionFactoryLookup"
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1872) deploy/undeploy archive and attachments issue
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1872:
--------------------------------------------
Summary: deploy/undeploy archive and attachments issue
Key: WFCORE-1872
URL: https://issues.jboss.org/browse/WFCORE-1872
Project: WildFly Core
Issue Type: Bug
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
When an archive is used to deploy/undeploy, an internal batch is created. All commands/operations located in the CLI archive script file are then added to the batch. The attachments associated to this internal batch are not taken into account.
When deploy/undeploy archive is executed, these attachments should be added to the executed operation.
When deploy/undeploy archive are added to a batch, the files attached by commands/operations located in the CLI script should be attached to the parent batch.
I also noticed that deploy <file> called in a batch context doesn't make use of attachment. It reads the file content and inline it in the request content. This does create a duplication of logic (execution and batch are handled differently).
NB: Fixing this issue in current WildFly CLI would be quite complex. It has been fixed in the CLI.next project. Files are now all the time attached, deploy/undeploy archive attachments are properly handled.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7100) Add JGroups-based SingletonServiceBuilderFactory implementation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7100?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-7100:
-------------------------------
Summary: Add JGroups-based SingletonServiceBuilderFactory implementation (was: Reimplement Singleton services using JGroups instead of Infinispan)
> Add JGroups-based SingletonServiceBuilderFactory implementation
> ---------------------------------------------------------------
>
> Key: WFLY-7100
> URL: https://issues.jboss.org/browse/WFLY-7100
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> The singleton subsystem currently requires the Infinispan subsystem. To minimize the requirements for using the singleton subsystem within the context of the host-controller, we should reimplement singleton service using JGroups directly, instead of requiring an Infinispan cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman commented on WFLY-5213:
-------------------------------------
I checked your client and its fine, on MDB site you have to use @ResourceAdapter(value="remote-artemis")just above "public class MessageConsiumer implements MessageListener ". I think you can safely remove "connectionFactoryLookup"
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7333) messaging-activemq resources are not recursively removed.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7333?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-7333:
------------------------------
Summary: messaging-activemq resources are not recursively removed. (was: EAP is unable to remove cloned full-ha profile)
> messaging-activemq resources are not recursively removed.
> ---------------------------------------------------------
>
> Key: WFLY-7333
> URL: https://issues.jboss.org/browse/WFLY-7333
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> *Description:*
> EAP is unable to remove cloned full-ha profile. This is regression against EAP 7.1.0.DR5. "clone" management operation was introduced in EAP7-35
> *Steps to reproduce:*
> # ./domain.sh
> # ./jboss-cli.sh -c
> # /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> # /profile=cli-clone-profile-first-full-ha:remove
> *Actual results:*
> {noformat}
> [mkopecky@dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
> [domain@localhost:9990 /] /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@localhost:9990 /] /profile=cli-clone-profile-first-full-ha:remove
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0368: Cannot remove capability 'org.wildfly.clustering.jgroups.default-channel-factory' from context 'profile=cli-clone-profile-first-full-ha' as it is required by other capabilities:
> capability 'org.wildfly.messaging.activemq.broadcast-group.channel-factory.bg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1'
> capability 'org.wildfly.messaging.activemq.discovery-group.channel-factory.dg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/discovery-group=dg-group1'"},
> "rolled-back" => true
> }
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7333) EAP is unable to remove cloned full-ha profile
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7333?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-6472 to WFLY-7333:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7333 (was: JBEAP-6472)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: Clustering)
(was: Domain Management)
(was: JMS)
> EAP is unable to remove cloned full-ha profile
> ----------------------------------------------
>
> Key: WFLY-7333
> URL: https://issues.jboss.org/browse/WFLY-7333
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> *Description:*
> EAP is unable to remove cloned full-ha profile. This is regression against EAP 7.1.0.DR5. "clone" management operation was introduced in EAP7-35
> *Steps to reproduce:*
> # ./domain.sh
> # ./jboss-cli.sh -c
> # /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> # /profile=cli-clone-profile-first-full-ha:remove
> *Actual results:*
> {noformat}
> [mkopecky@dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
> [domain@localhost:9990 /] /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@localhost:9990 /] /profile=cli-clone-profile-first-full-ha:remove
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0368: Cannot remove capability 'org.wildfly.clustering.jgroups.default-channel-factory' from context 'profile=cli-clone-profile-first-full-ha' as it is required by other capabilities:
> capability 'org.wildfly.messaging.activemq.broadcast-group.channel-factory.bg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1'
> capability 'org.wildfly.messaging.activemq.discovery-group.channel-factory.dg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/discovery-group=dg-group1'"},
> "rolled-back" => true
> }
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months