[JBoss JIRA] (WFCORE-3748) Copying lot of commands into CLI prompt fails
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3748?page=com.atlassian.jira.plugi... ]
Erich Duda commented on WFCORE-3748:
------------------------------------
I confirm that scenarios given in this Jira works with Wildfly Core 5.0.0.Beta1.
> Copying lot of commands into CLI prompt fails
> ---------------------------------------------
>
> Key: WFCORE-3748
> URL: https://issues.jboss.org/browse/WFCORE-3748
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.0.0.Alpha3
> Reporter: Martin Choma
> Assignee: Jean-Francois Denise
> Fix For: 5.0.0.Beta1
>
>
> Running commands with --file option works OK. Copying commands one by one works OK
> Seems to me as something is beeing overflowed.
> {code}
> [standalone@localhost:9990 /] # prepare server and client key materials
> [standalone@localhost:9990 /] # generate server keystore
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server_keystore:add(type=PKCS12, credential-reference={clear-text=secret},path=/tmp/server.keystore)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server_keystore:generate-key-pair(alias=server, distinguished-name="CN=server")
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server_keystore:export-certificate(alias=server,path=/tmp/server.certificate.pem,pem=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] # generate client keystore
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=client_keystore:add(type=PKCS12, credential-reference={clear-text=secret},path=/tmp/client.keystore)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=client_keystore:generate-key-pair(alias=client, distinguished-name="CN=client")
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=client_keystore:export-certificate(alias=clieytron/key-store=client_truststore:import-certificate(alias=server,path=/tmp/server.certificate.pem,validate=false
> Closing ')' is missing.
> [standalone@localhost:9990 /] # save it all
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server_keystore:store()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=client_keystore:store()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server_truststore:store()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"key-store\" => \"server_truststore\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=client_truststore:store()
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9941) :shutdown cli operation throws java.util.concurrent.CancellationException: Operation was cancelled
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-9941?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-9941.
--------------------------------
Resolution: Done
[~jdenise] Yes, it's ok after change. Closing.
> :shutdown cli operation throws java.util.concurrent.CancellationException: Operation was cancelled
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-9941
> URL: https://issues.jboss.org/browse/WFLY-9941
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jean-Francois Denise
> Attachments: manu-trace.log
>
>
> There is intermittent failure on CLI client when CLI operation {{ :shutdown() }} is called. Sometimes happens that CancellationException is thrown:
> {code}
> 2018-03-01 09:36:59,188 ERROR pool-1-thread-1 org.jboss.manu.eap.services.server.EapModularServerBase - Can't stop server gracefully
> java.io.IOException: java.util.concurrent.CancellationException: Operation was cancelled
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.execute(OnlineManagementClientImpl.java:180) ~[creaper-core-1.6.1.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.executeOnlineManagementOperation(EapModularServerBase.java:600) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.executeOnlineManagementOperation(EapModularServerBase.java:638) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapServerStandalone.executeStopOperation(EapServerStandalone.java:348) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.stop(EapModularServerBase.java:238) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.units.server.StopServer.execute(StopServer.java:57) [manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.core.execute.UnitExecuteTask.call(UnitExecuteTask.java:33) [manu-core-impl-1.1.43.jar:na]
> at org.jboss.manu.core.execute.UnitExecuteTask.call(UnitExecuteTask.java:14) [manu-core-impl-1.1.43.jar:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.util.concurrent.CancellationException: Operation was cancelled
> at org.jboss.threads.AsyncFutureTask.operationCancelled(AsyncFutureTask.java:70) ~[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:267) ~[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:57) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> ... 13 common frames omitted
> {code}
> WF12 server shutdowns but it seems that it does not send response for {{:shutdown}} call to client before shutdwon and closes connection. This causes that AsyncFutureTask on client is cancelled.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ]
Miroslav Novak commented on WFCORE-3450:
----------------------------------------
Yes, this can be resolved.
> CLI - avoid required attributes to be hard to see when using tab completion
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3450
> URL: https://issues.jboss.org/browse/WFCORE-3450
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Miroslav Novak
> Assignee: Ingo Weiss
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier
> allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors*
> call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection
> call-timeout connection-ttl max-hops notification-attempts retry-interval
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3895) module.path of embedded server cannot be modified after it is set
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3895?page=com.atlassian.jira.plugi... ]
Erich Duda closed WFCORE-3895.
------------------------------
Resolution: Explained
> module.path of embedded server cannot be modified after it is set
> -----------------------------------------------------------------
>
> Key: WFCORE-3895
> URL: https://issues.jboss.org/browse/WFCORE-3895
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Affects Versions: 5.0.0.Beta5
> Reporter: Erich Duda
> Assignee: James Perkins
> Priority: Blocker
>
> *Scenario:*
> * Run CLI in non-modular class loading mode.
> * Run embed-server with {{--jboss-home}} pointing to server A
> * Stop embed-server
> * Remove server A
> * Run embed-server with {{--jboss-home}} pointing to server B
> *Expectation:* embed-server with {{--jboss-home}} pointing to server B will boot.
> *Reality*: The following error message is thrown. As you can see the embed server tries to load modules from server A directory even if the jboss-home was set to server B.
> {code}
> Cannot start embedded server: The first directory of the specified module path /home/eduda/Projects/wildfly/dist/target/wildfly-A/modules is invalid or does not exist.
> {code}
> *Users impact:* Behavior of non-modular class loading \[1\] has changed. This change can break user's automation or tests.
> *Blocker priority* was chosen because this is change in behavior against Wildfly 12.
> *Technical details*
> When the embed-server is started for the second time, following warning is logged.
> {code}
> 2018-05-28 08:10:57,621 WARN [org.jboss.as.embedded] (main) WFLYEMB0145: The module loader has already been configured. Changing the module.path property will have no effect
> {code}
> It seems that the change in behavior was caused by commit \[2\].
> \[1\] http://wildfly.org/news/2015/03/13/Offline-CLI/#classloading
> \[2\] https://github.com/wildfly/wildfly-core/commit/22f3956f1adcdf8b1cb11e24f2...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3895) module.path of embedded server cannot be modified after it is set
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3895?page=com.atlassian.jira.plugi... ]
Erich Duda commented on WFCORE-3895:
------------------------------------
[~jamezp] After your response I double checked the behavior of WF 12. WF 12 boots, but when I reloaded the server, it tried to load jars from original location and failed. So I confirm that the module path wasn't allowed to be changed in WF 12 either.
bq. An error shouldn’t be thrown, but it should be logging a message.
The error is thrown only if the original directory with jars is removed. Otherwise only message is logged and the server boots with jars from original location.
Closing.
> module.path of embedded server cannot be modified after it is set
> -----------------------------------------------------------------
>
> Key: WFCORE-3895
> URL: https://issues.jboss.org/browse/WFCORE-3895
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Affects Versions: 5.0.0.Beta5
> Reporter: Erich Duda
> Assignee: James Perkins
> Priority: Blocker
>
> *Scenario:*
> * Run CLI in non-modular class loading mode.
> * Run embed-server with {{--jboss-home}} pointing to server A
> * Stop embed-server
> * Remove server A
> * Run embed-server with {{--jboss-home}} pointing to server B
> *Expectation:* embed-server with {{--jboss-home}} pointing to server B will boot.
> *Reality*: The following error message is thrown. As you can see the embed server tries to load modules from server A directory even if the jboss-home was set to server B.
> {code}
> Cannot start embedded server: The first directory of the specified module path /home/eduda/Projects/wildfly/dist/target/wildfly-A/modules is invalid or does not exist.
> {code}
> *Users impact:* Behavior of non-modular class loading \[1\] has changed. This change can break user's automation or tests.
> *Blocker priority* was chosen because this is change in behavior against Wildfly 12.
> *Technical details*
> When the embed-server is started for the second time, following warning is logged.
> {code}
> 2018-05-28 08:10:57,621 WARN [org.jboss.as.embedded] (main) WFLYEMB0145: The module loader has already been configured. Changing the module.path property will have no effect
> {code}
> It seems that the change in behavior was caused by commit \[2\].
> \[1\] http://wildfly.org/news/2015/03/13/Offline-CLI/#classloading
> \[2\] https://github.com/wildfly/wildfly-core/commit/22f3956f1adcdf8b1cb11e24f2...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3897) Host starts with server assigned to non-existent server group
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3897?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-14808 to WFCORE-3897:
-------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3897 (was: JBEAP-14808)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Server)
Affects Version/s: 5.0.0.CR1
(was: 7.1.2.GA)
> Host starts with server assigned to non-existent server group
> -------------------------------------------------------------
>
> Key: WFCORE-3897
> URL: https://issues.jboss.org/browse/WFCORE-3897
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.0.0.CR1
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Configuring a host with:
> <server name="server-one" group="main-server-group" auto-start="false"/>
> <server name="server-two" group="main-server-group" auto-start="false">
> <socket-bindings port-offset="150"/>
> </server>
> And no server-goup with that name in the domain.xml, the host starts and all management operations fail.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10467) Drop support for mod_cluster subsystem model versions prior 1.5.0
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-10467?page=com.atlassian.jira.plugin... ]
Michal Karm Babacek commented on WFLY-10467:
--------------------------------------------
Excellent clean up plan. My head was spinning from the config model.
> Drop support for mod_cluster subsystem model versions prior 1.5.0
> -----------------------------------------------------------------
>
> Key: WFLY-10467
> URL: https://issues.jboss.org/browse/WFLY-10467
> Project: WildFly
> Issue Type: Task
> Components: mod_cluster
> Affects Versions: 13.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> * No need to keep unused model version 1.4.0 in enumeration.
> * No need to keep transformer logic prior 1.5.0 which is the lowest supported (session draining strategy was supported in EAP 6.3/6.4 so no need to transform to older).
> * No need for org.wildfly.extension.mod_cluster.controller.SessionDrainingStrategyChecker
> * No need for 1.5.0 config in org.wildfly.extension.mod_cluster.ModClusterTransformersTestCase#createFailedOperationConfig
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9941) :shutdown cli operation throws java.util.concurrent.CancellationException: Operation was cancelled
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9941?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise commented on WFLY-9941:
--------------------------------------------
[~mnovak], are the tests now relying on shutdown command? Can we close this one? Thanks.
> :shutdown cli operation throws java.util.concurrent.CancellationException: Operation was cancelled
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-9941
> URL: https://issues.jboss.org/browse/WFLY-9941
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jean-Francois Denise
> Attachments: manu-trace.log
>
>
> There is intermittent failure on CLI client when CLI operation {{ :shutdown() }} is called. Sometimes happens that CancellationException is thrown:
> {code}
> 2018-03-01 09:36:59,188 ERROR pool-1-thread-1 org.jboss.manu.eap.services.server.EapModularServerBase - Can't stop server gracefully
> java.io.IOException: java.util.concurrent.CancellationException: Operation was cancelled
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.execute(OnlineManagementClientImpl.java:180) ~[creaper-core-1.6.1.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.executeOnlineManagementOperation(EapModularServerBase.java:600) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.executeOnlineManagementOperation(EapModularServerBase.java:638) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapServerStandalone.executeStopOperation(EapServerStandalone.java:348) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.stop(EapModularServerBase.java:238) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.units.server.StopServer.execute(StopServer.java:57) [manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.core.execute.UnitExecuteTask.call(UnitExecuteTask.java:33) [manu-core-impl-1.1.43.jar:na]
> at org.jboss.manu.core.execute.UnitExecuteTask.call(UnitExecuteTask.java:14) [manu-core-impl-1.1.43.jar:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.util.concurrent.CancellationException: Operation was cancelled
> at org.jboss.threads.AsyncFutureTask.operationCancelled(AsyncFutureTask.java:70) ~[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:267) ~[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:57) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> ... 13 common frames omitted
> {code}
> WF12 server shutdowns but it seems that it does not send response for {{:shutdown}} call to client before shutdwon and closes connection. This causes that AsyncFutureTask on client is cancelled.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3450:
----------------------------------------------
[~mnovak], we have added colouring for required operation arguments in WFCORE-3577, I think that it makes it clear what are the one required. Can we resolve this one?
> CLI - avoid required attributes to be hard to see when using tab completion
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3450
> URL: https://issues.jboss.org/browse/WFCORE-3450
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Miroslav Novak
> Assignee: Ingo Weiss
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier
> allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors*
> call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection
> call-timeout connection-ttl max-hops notification-attempts retry-interval
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months