[JBoss JIRA] (WFCORE-362) fix jvm management model for server and groups
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-362?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-532 to WFCORE-362:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-362 (was: WFLY-532)
Affects Version/s: (was: 8.0.0.Alpha1)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> fix jvm management model for server and groups
> ----------------------------------------------
>
> Key: WFCORE-362
> URL: https://issues.jboss.org/browse/WFCORE-362
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Labels: rhq
> Fix For: 1.0.0.Beta1
>
>
> We need to update the JVM child resource definition for server-groups and servers to only allow a single JVM configuration (i.e. configuration=JVM) resource. Currently only the first configured VM is used, where the name is the reference to the corresponding host level JVM.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2883 to WFCORE-363:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-363 (was: WFLY-2883)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-364) Hangs in mixed domain testsuite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-364?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1536 to WFCORE-364:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-364 (was: WFLY-1536)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> Hangs in mixed domain testsuite
> -------------------------------
>
> Key: WFCORE-364
> URL: https://issues.jboss.org/browse/WFCORE-364
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
> Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull...
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFLY-2742) Domain rollout operation timeouts
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2742?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2742:
-----------------------------------
Parent: (was: WFLY-2740)
Issue Type: Feature Request (was: Sub-task)
> Domain rollout operation timeouts
> ---------------------------------
>
> Key: WFLY-2742
> URL: https://issues.jboss.org/browse/WFLY-2742
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> Portion of the parent task related to rolling out changes to a domain.
> The expectation is that single process timeouts (WFLY-2741) will handle most failure conditions related to domain rollouts (e.g. if a single server hangs, preventing completion of the rollout, eventually that server will time out, allowing the domain wide rollout to continue.) Timeouts in the domain rollout code serve as a second line of defense:
> 1) In case of protocol or other problems that prevent the calling process learning about the timeout on the remote process
> 2) In case of bugs in the single process timeout handling on the remote process
> 3) In mixed domain cases where remote hosts are running previous versions and do not have the timeout function
> Potential places to add timeouts:
> DomainSlaveHandler->HostControllerUpdateTask.ProxyOperationListener.retrievePreparedOperation()
> -- where the master HC waits for responses from slaves
> RollingServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
> -- timeout here means 1 server didn't respond, but need to move on to next
> ConcurrentServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
> -- timeout here means none of the remaining servers have responded w/in the timeout
> DomainRolloutStepHandler.finalizeOp() -> future.get()
> ---- the ServerGroupUpdateTask should fail in the normal phase, so any timeout here would indicate a problem committing the tx or a comms problem getting back the response
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFLY-2741) Single process management operation timeouts
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2741?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2741:
-----------------------------------
Parent: (was: WFLY-2740)
Issue Type: Feature Request (was: Sub-task)
> Single process management operation timeouts
> --------------------------------------------
>
> Key: WFLY-2741
> URL: https://issues.jboss.org/browse/WFLY-2741
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Alpha1
>
>
> Portion of the parent task related to operation execution within a single process (i.e. not involving intra-process calls in a domain).
> Potential points to apply the timeout:
> ModelControllerImpl.acquireLock()
> Questionable, as blocking here means waiting for another op, not a problem with the current op
> ModelControllerImpl.awaitContainerMonitor() -> ContainerStateMonitor.await() -> StabilityMonitor.awaitStability()
> This is the typical blocking point in a server op
> -- on way in, fail the op
> -- on way out (OperationContextImpl.releaseStepLocks()) log a WARN/ERROR
> ModelControllerImpl.awaitContainerStateChangedReport()
> -- on the way in, before VERIFY
> OperationContextImpl.waitForRemovals()
> -- on way in, before VERIFY
> -- on way out, in handleRollback
> ---- problem: this is called repeatedly
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-360) HTTP management API section in the Admin Guide
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-360?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-748 to WFCORE-360:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-360 (was: WFLY-748)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: (was: No Release)
> HTTP management API section in the Admin Guide
> ----------------------------------------------
>
> Key: WFCORE-360
> URL: https://issues.jboss.org/browse/WFCORE-360
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
>
> We need a technical guide to the HTTP management API.
> The "Management clients" section gives a basic overview. But it should reference a separate section that documents the usage of GET and POST, the URL patterns, the JSON representation of DMR etc.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-358) Add a generic query facility
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-358?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-708 to WFCORE-358:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-358 (was: WFLY-708)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: (was: Awaiting Volunteers)
> Add a generic query facility
> ----------------------------
>
> Key: WFCORE-358
> URL: https://issues.jboss.org/browse/WFCORE-358
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Rupp
> Labels: rhq
>
> To find out, which e.g. jdbc drivers are deployed on a server group, I have to visit each managed server and query it. This is cumbersome
> - first the server group should have the same driver for all servers, so asking the server group should be enough
> - as the server group does not even know its connected managed servers (there is no :list-servers) operation, I need to potentially loop over the whole domain including tons of remote HC in order to query for e.g. the jdbc drivers or other stuff
> There should be a mechanism to fire queries at which then get relayed to the HCs and the answers combined and returned.
> Still I don't get why if a server-group is meant to contain an identical configuration for all its managed servers (besides VM params, ports and IPs) it does not just have "proxy methods" like :installed-drivers-list or :server-list etc.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months