[JBoss JIRA] (WFCORE-742) Unify linux and PowerShell scripts for jboss-cli in printing environment information
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-742?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-742:
------------------------------
Fix Version/s: 2.0.0.CR7
(was: 2.0.0.CR6)
> Unify linux and PowerShell scripts for jboss-cli in printing environment information
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-742
> URL: https://issues.jboss.org/browse/WFCORE-742
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.0.Alpha3
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.CR7
>
>
> Powershell script jboss-cli.ps1 prints environment information.
> *Steps to Reproduce:*
> # .\jboss-cli.ps1
> *Actual results:*
> {noformat}
> =========================================================================
> WildFly Bootstrap Environment
> JBOSS_HOME: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0
> JBOSS_BASE_DIR: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0\standalone
> JAVA: java
> JAVA_OPTS: -Xms64M -Xmx512M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.ne
> t.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman
> JBOSS_MODULEPATH: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0\modules
> =========================================================================
> 10:22:33,569 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 10:22:33,959 INFO [org.jboss.as.cli.CommandContext] (main) You are disconnected at the moment. Type 'connect' to connec
> t to the server or 'help' for the list of supported commands.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands
> .
> [disconnected /]
> {noformat}
> *Expected results:*
> {noformat}
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /]
> {noformat}
> \\
> \\
> ".\jboss-cli.ps1 --help" show too much logging information:
> *Steps to Reproduce:*
> # .\jboss-cli.ps1 --help
> *Actual results:*
> {noformat}
> ...
> 10:29:18,212 INFO [org.jboss.as.cli.CommandContext] (main) Usage:
> Usage:
> 10:29:18,215 INFO [org.jboss.as.cli.CommandContext] (main)
> 10:29:18,216 INFO [org.jboss.as.cli.CommandContext] (main) jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> ...
> {noformat}
> *Expected results:*
> {noformat}
> Usage:
> jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1030) PS1 scripts for standalone and domain do not survive :shutdown(restart=true)
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1030?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1030:
-------------------------------
Fix Version/s: 2.0.0.CR7
(was: 2.0.0.CR6)
> PS1 scripts for standalone and domain do not survive :shutdown(restart=true)
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1030
> URL: https://issues.jboss.org/browse/WFCORE-1030
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Rostislav Svoboda
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.CR7
>
>
> PS1 scripts for standalone and domain do not survive :shutdown(restart=true)
> {code}
> [standalone@localhost:9990 /] :shutdown(restart=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] ls
> Failed to perform operation: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://localhost:9990.
> The connection failed: WFLYPRT0053: Could not connect to http-remoting://localhost:9990.
> The connection failed: Connection refused: no further information
> {code}
> Domain the same
> {code}
> [domain@localhost:9990 /] /host=master:shutdown(restart=true)
> ...
> {code}
> FYI - scripts were taken from https://github.com/ctomc/wildfly-core/commits/powershell
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1016) NPE or AssertionError if op is cancelled on slave between sending prepare and receiving commit/rollback
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1016?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1016:
-------------------------------
Fix Version/s: 2.0.0.CR7
(was: 2.0.0.CR6)
> NPE or AssertionError if op is cancelled on slave between sending prepare and receiving commit/rollback
> -------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1016
> URL: https://issues.jboss.org/browse/WFCORE-1016
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR7
>
>
> OperationCancellationTestCase showed this failure:
> {code}
> 2015-09-23 06:43:40,147 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) block requested by testSlaveBlockCompletionCancelSlave for slave/undefined(COMMIT)
> 2015-09-23 06:43:40,147 INFO [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) will block at COMMIT for 20000
> 2015-09-23 06:43:40,164 INFO [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 71) WFLYCTL0352: Cancelling operation 'block' with id '1900489784' running on thread 'Host Controller Service Threads - 82'
> 2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) Exception in thread "Host Controller Service Threads - 82" java.lang.AssertionError
> 2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.completed(TransactionalProtocolOperationHandler.java:475)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at java.security.AccessController.doPrivileged(Native Method)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at javax.security.auth.Subject.doAs(Subject.java:360)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at java.security.AccessController.doPrivileged(Native Method)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at java.lang.Thread.run(Thread.java:745)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> What happens here is the slave HC executing the 'block' op has sent a prepare message to the master, and then when the commit has not come back yet the test driver triggers a cancel on the slave. At this point the thread running the 'block' op returns and tries to send the final result to the master. But it fails because the prepare logic has nulled out the responseChannel field, and the commit message has not arrived yet to restore a new one.
> If assertions weren't enabled, the result would be an NPE when the null responseChannel is used.
> I don't see any reason for null out the responseChannel.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1027) Inconsistent read-resource results with host scoped roles
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1027?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1027:
-------------------------------
Fix Version/s: 2.0.0.CR7
(was: 2.0.0.CR6)
> Inconsistent read-resource results with host scoped roles
> ---------------------------------------------------------
>
> Key: WFCORE-1027
> URL: https://issues.jboss.org/browse/WFCORE-1027
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.0.CR7
>
>
> Setting up host scoped roles as follows https://gist.github.com/heiko-braun/0dc810ed04db8739defd there are inconsistent results in the filtering. When using a role which only selects the master there is no access-control response header showing the filtered resources, and the slave wrongly appears in the results:
> {code}
> [domain@localhost:9990 /] /host=*:read-resource{roles=master-monitor}
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [("host" => "master")],
> "outcome" => "success",
> "result" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 4,
> "management-micro-version" => 0,
> "management-minor-version" => 0,
> "master" => true,
> "name" => "master",
> "namespaces" => [],
> "organization" => undefined,
> "product-name" => "WildFly Core",
> "product-version" => "2.0.0.CR6-SNAPSHOT",
> "release-codename" => "Kenny",
> "release-version" => "2.0.0.CR6-SNAPSHOT",
> "schema-locations" => [],
> "core-service" => {
> "host-environment" => undefined,
> "platform-mbean" => undefined,
> "management" => undefined,
> "discovery-options" => undefined,
> "ignored-resources" => undefined,
> "patching" => undefined,
> "module-loading" => undefined
> },
> "extension" => {"org.jboss.as.jmx" => undefined},
> "interface" => {
> "management" => undefined,
> "public" => undefined,
> "unsecure" => undefined
> },
> "jvm" => {"default" => undefined},
> "path" => undefined,
> "server" => {
> "server-one" => undefined,
> "server-two" => undefined,
> "server-three" => undefined
> },
> "server-config" => {
> "server-one" => undefined,
> "server-two" => undefined,
> "server-three" => undefined
> },
> "socket-binding-group" => undefined,
> "subsystem" => {"jmx" => undefined},
> "system-property" => undefined
> }
> },
> {
> "address" => [("host" => "localhost")],
> "outcome" => "success",
> "result" => undefined
> }
> ]
> }
> {code}
> When using a role that only selects the slave we get a proper access-control header
> {code}
> [domain@localhost:9990 /] /host=*:read-resource{roles=slave-maintainer}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("host" => "localhost")],
> "outcome" => "success",
> "result" => undefined
> }],
> "response-headers" => {"access-control" => [{
> "absolute-address" => [],
> "relative-address" => [],
> "filtered-children-types" => ["host"]
> }]}
> {code}
> The same output on master with WFCORE-994 applied:
> {code}
> [domain@localhost:9990 /] /host=*:read-resource{roles=slave-maintainer}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("host" => "slave")],
> "outcome" => "success",
> "result" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"remote" => {
> "protocol" => undefined,
> "port" => undefined,
> "host" => undefined,
> "username" => undefined,
> "ignore-unused-configuration" => undefined,
> "admin-only-policy" => undefined,
> "security-realm" => "ManagementRealm"
> }},
> "management-major-version" => 4,
> "management-micro-version" => 0,
> "management-minor-version" => 0,
> "master" => false,
> "name" => "slave",
> "namespaces" => [],
> "organization" => undefined,
> "product-name" => undefined,
> "product-version" => undefined,
> "release-codename" => "Kenny",
> "release-version" => "2.0.0.CR6-SNAPSHOT",
> "schema-locations" => [],
> "core-service" => {
> "host-environment" => undefined,
> "platform-mbean" => undefined,
> "management" => undefined,
> "discovery-options" => undefined,
> "ignored-resources" => undefined,
> "patching" => undefined,
> "module-loading" => undefined
> },
> "extension" => {"org.jboss.as.jmx" => undefined},
> "interface" => {
> "management" => undefined,
> "public" => undefined,
> "unsecure" => undefined
> },
> "jvm" => {"default" => undefined},
> "path" => undefined,
> "server" => {
> "server-one" => undefined,
> "server-two" => undefined
> },
> "server-config" => {
> "server-one" => undefined,
> "server-two" => undefined
> },
> "socket-binding-group" => undefined,
> "subsystem" => {"jmx" => undefined},
> "system-property" => undefined
> }
> }],
> "response-headers" => {"access-control" => [{
> "absolute-address" => [],
> "relative-address" => [],
> "filtered-children-types" => ["host"]
> }]}
> }
> {code}
> master-monitor should behave the same as slave-maintainer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1025) ManagementRequestContext executeAsync hides RejectedExecutionException
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1025?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1025:
-------------------------------
Fix Version/s: 2.0.0.CR7
(was: 2.0.0.CR6)
> ManagementRequestContext executeAsync hides RejectedExecutionException
> ----------------------------------------------------------------------
>
> Key: WFCORE-1025
> URL: https://issues.jboss.org/browse/WFCORE-1025
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR7
>
>
> The impl of ManagementRequestContext executeAsync catches RejectedExecutionException and doesn't notify the calling thread. The handling itself seems ok (call failed on the result handler and send a failure response to the client), but not notifying the caller is problematic. There are a number of cases where the caller thread waits for a latch to be tripped, with the async task tripping. If the latch never trips, the caller thread will block forever. The testsuite hang at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=71233&buildTyp... looks to be a case of this, with a server not stopping due to this:
> {code}
> "Remoting "master:main-one:MANAGEMENT" task-13" #55 prio=5 os_prio=0 tid=0xc6c3bc00 nid=0x19d9 waiting on condition [0xc215c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xddbb4aa0> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.sendResponse(TransactionalProtocolOperationHandler.java:540)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:377)
> - locked <0xddbb2300> (a org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext)
> at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl$2.handleFailed(ActiveOperationSupport.java:350)
> at org.jboss.threads.AsyncFutureTask$Reg.run(AsyncFutureTask.java:60)
> at org.jboss.as.protocol.mgmt.ActiveOperationSupport$1.execute(ActiveOperationSupport.java:55)
> at org.jboss.threads.AsyncFutureTask.safeExecute(AsyncFutureTask.java:169)
> at org.jboss.threads.AsyncFutureTask.setFailed(AsyncFutureTask.java:162)
> at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl.access$400(ActiveOperationSupport.java:295)
> at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl$1.failed(ActiveOperationSupport.java:315)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2.executeAsync(AbstractMessageHandler.java:333)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2.executeAsync(AbstractMessageHandler.java:315)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.handleRequest(TransactionalProtocolOperationHandler.java:144)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The RejectedExecutionException indicates a thread pool has been shutdown before the response has gone out. Ideally we would prevent that (for which I've recently filed a JIRA) but in any case we should make this more robust.
> I think having executeAsync return a boolean should suffice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months