[JBoss JIRA] (WFLY-6600) NPE thrown during EAR deployment
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6600?page=com.atlassian.jira.plugin.... ]
jaikiran pai edited comment on WFLY-6600 at 5/28/16 2:18 AM:
-------------------------------------------------------------
I just sent a PR https://github.com/wildfly/wildfly/pull/8938 which should prevent this NPE
was (Author: jaikiran):
I just sent a PR which should prevent this NPE
> NPE thrown during EAR deployment
> --------------------------------
>
> Key: WFLY-6600
> URL: https://issues.jboss.org/browse/WFLY-6600
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
>
> We deploy an EAR file to a Wildfly domain with two slaves. On one slave, we'll frequently see this exception:
> {code}
> [Server:main-server] 2016-05-08 16:06:13+1000 INFO [[org.jboss.as.server]] [[ServerService Thread Pool -- 359]] WFLYSRV0016: Replaced deployment "services.war" with deployment "services.war"
> [Server:main-server] 2016-05-09 06:05:08+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 384]] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:main-server] ("deployment" => "OnlineSystemsApplications.ear"),
> [Server:main-server] ("subdeployment" => "systemcheck.war"),
> [Server:main-server] ("subsystem" => "undertow"),
> [Server:main-server] ("servlet" => "javax.ws.rs.core.Application")
> [Server:main-server] ]): java.lang.NullPointerException
> [Server:main-server] at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:125)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> At the same time we'll see this on the second node
> {code}
> [Server:main-server] 2016-05-06 16:17:59+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 276]] WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$4@14bd8919 for operation {"operation" => "full-replace-deployment","name" => "OnlineSystemsApplications.ear","enabled" => true,"content" => [{"hash" => bytes { 0x73, 0xec, 0x83, 0x82, 0xb6, 0x67, 0x2d, 0x92, 0x36, 0x7a, 0xb7, 0x7c, 0x7a, 0x4e, 0xc4, 0x93, 0x00, 0xc1, 0xf3, 0xc3 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "76dbe681-46d0-4f2e-a4c7-82f615919ff0"},"address" => [],"runtime-name" => undefined,"persistent" => true,"owner" => undefined} at address [] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-server] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377)
> [Server:main-server] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299)
> [Server:main-server] at org.jboss.dmr.ModelNode.require(ModelNode.java:870)
> [Server:main-server] at org.jboss.as.server.deployment.DeploymentHandlerUtil$4$1.handleResult(DeploymentHandlerUtil.java:277)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The WAR file in question doesn't actually use JAX-RS, so I'm not sure why javax.ws.rs.core.Application would be causing any issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6656) add-user.sh does not return the secret value in non-interactive mode.
by Petros Petrou (JIRA)
[ https://issues.jboss.org/browse/WFLY-6656?page=com.atlassian.jira.plugin.... ]
Petros Petrou commented on WFLY-6656:
-------------------------------------
I will be start working on this. I have looked into the source code as I needed to see how the secret value is calculated. I will contribute so this feature is supported by the product.
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFLY-6656
> URL: https://issues.jboss.org/browse/WFLY-6656
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.0.0.Final
> Reporter: Petros Petrou
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Jose Cavieres (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Jose Cavieres updated DROOLS-987:
---------------------------------
Workaround Description: To use ReteOO
Workaround: Workaround Exists
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Jose Cavieres (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Jose Cavieres commented on DROOLS-987:
--------------------------------------
The problem is still happening in 6.4.0.Final.
Because of this issue, I don't believe it's feasible to use Phreak in multithreaded environments. The only workaround we fount was to continue to use ReteOO
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Jose Cavieres (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Jose Cavieres updated DROOLS-987:
---------------------------------
Affects Version/s: 6.4.0.Final
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1573) RemotingModelControllerClient can hang on close
by David Lloyd (JIRA)
David Lloyd created WFCORE-1573:
-----------------------------------
Summary: RemotingModelControllerClient can hang on close
Key: WFCORE-1573
URL: https://issues.jboss.org/browse/WFCORE-1573
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: David Lloyd
Assignee: David Lloyd
RemotingModelControllerClient closes its Remoting endpoint. While generally not correct, this can still be done if the close is performed asynchronously. We can revisit the relationship between the remote controller client and its connections and endpoints at a later time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1570) Saved rollout-plan 'name' or 'id' attribute discrepancy
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1570?page=com.atlassian.jira.plugi... ]
Bartosz Spyrko-Śmietanko updated WFCORE-1570:
---------------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1583
> Saved rollout-plan 'name' or 'id' attribute discrepancy
> -------------------------------------------------------
>
> Key: WFCORE-1570
> URL: https://issues.jboss.org/browse/WFCORE-1570
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha1
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Priority: Minor
>
> When using rollout plans for EAP deployment scenarios I can create my own named rollout-plan for ease of use. I can then apply rollout command later on, referring with name of my own rollout plan that should be used. There is minor discrepancy in the way I create and use such rollout plan though.
> When I create rollout-plan, I use command like:
> {code}
> rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}
> {code}
> - see {{--name}} attribute given to name my rollout plan
> When I then refer to it I use following command:
> {code}
> deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
> {code}
> - see {{id}} attribute given to {{rollout}} header operation
> Yes, this is really minor issue, but I think that these two attributes used in aforementioned commands should be unified (preferably to {{name}} instead of {{id}}) as user might be confused when using it.
> Note: examples are used from our documentation.
> Note: I do not know whether I am missing something but I was not able to retrieve more info how to use {{rollout}} header operation in deploy command directly in CLI.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1572) Suggestion list for argument value is not generated if the value contains a whitespace
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1572?page=com.atlassian.jira.plugi... ]
Bartosz Spyrko-Śmietanko moved JBEAP-4751 to WFCORE-1572:
---------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1572 (was: JBEAP-4751)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 3.0.0.Alpha1
(was: 7.0.0.GA)
> Suggestion list for argument value is not generated if the value contains a whitespace
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1572
> URL: https://issues.jboss.org/browse/WFCORE-1572
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha1
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
>
> When an argument value contains a space (eg. {{deploy /path/to/test-application.war --all-server-groups --headers=\{rollout id=foo\}}}) and if user hits tab after the whitespace, suggestions are generated based on the command, rather than the current argument's name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFCORE-1571) Do not wait indefinitely for a channel open to succeed
by David Lloyd (JIRA)
David Lloyd created WFCORE-1571:
-----------------------------------
Summary: Do not wait indefinitely for a channel open to succeed
Key: WFCORE-1571
URL: https://issues.jboss.org/browse/WFCORE-1571
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: David Lloyd
Assignee: David Lloyd
There is no need to wait forever for a management channel to open. If the open fails, we can just throw an exception and retry the connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months