[JBoss JIRA] (WFCORE-379) Give option to make the content repository browsable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-379?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-549 to WFCORE-379:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-379 (was: WFLY-549)
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)
> Give option to make the content repository browsable
> ----------------------------------------------------
>
> Key: WFCORE-379
> URL: https://issues.jboss.org/browse/WFCORE-379
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Schofield
> Fix For: 1.0.0.Beta1
>
>
> JBoss admins regularly need to view the application content that is deployed to a server. On previous versions of JBoss this was easy to do with the deploy directory. When using the new API to install applications the contents of applications are not easily browsable or searchable.
> Would like to have a setting that enables all content to be stored in exploded format in the content repository.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-365) inconsistent usage of min/max-occurs in model description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-365?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-142 to WFCORE-365:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-365 (was: WFLY-142)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> inconsistent usage of min/max-occurs in model description
> ---------------------------------------------------------
>
> Key: WFCORE-365
> URL: https://issues.jboss.org/browse/WFCORE-365
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Enrique González Martínez
> Fix For: 1.0.0.Beta1
>
> Attachments: patch.txt
>
>
> The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation.
> I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it.
> [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-366) Support timeout of management operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-366?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2740 to WFCORE-366:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-366 (was: WFLY-2740)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> Support timeout of management operations
> ----------------------------------------
>
> Key: WFCORE-366
> URL: https://issues.jboss.org/browse/WFCORE-366
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> There have been various situations where bugs in WF or in user code have prevented management operations from completing, leaving the ModelController locked permanently, unless the process is stopped. There should be mechanism via which timeouts can be set.
> My proposal is to allow a timeout to be set via a management operation header. In addition, there will be a standard timeout that will apply if no header is present.
> The standard timeout will be quite lengthy, probably several minutes. The goal is to allow a management process to eventually auto-recover, not to do prompt detection of failures. Users can use the header if they wish prompt detection a failures. A short standard timeout runs the risk of false positives, particularly with large deployments.
> The meaning of this timeout is not to be an overall maximum time for operation execution. There would be no valid default for such a timeout in a managed domain, where the time it would take to roll out a change would depend on the size of the domain and the rollout plan.
> Rather, this timeout is meant to be the maximum period operation execution threads can block in various points. Blocking for longer than the timeout would result in operation failure.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-368) Ability for processes to be placed in a state rejecting config changes and requiring a restart
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-368?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2882 to WFCORE-368:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-368 (was: WFLY-2882)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> Ability for processes to be placed in a state rejecting config changes and requiring a restart
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-368
> URL: https://issues.jboss.org/browse/WFCORE-368
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> If a condition occurs whereby a managed process is in an unknown and inconsistent state, we need the ability to mark the process as being unsafe to modify in terms of configuration and requiring restart.
> Examples of this kind of situation in a standalone server would include:
> 1) timeouts waiting for MSC stability as envisioned in WFLY-2741.
> 2) failures that occur in operation rollback.
> In these cases, it is no longer practical to determine how internal service state relates to configuration state. Allowing further configuration changes will exacerbate the situation. The process should be restarted in order to restore consistency before allowing further config changes.
> In a domain environment this can also include servers that are inconsistent with respect to the domain model because some update has failed on that server but the rollout plan allowed the update to commit on other servers.
> In this case, the server config is inconsistent with the domain and subsequent changes to the domain will not make it consistent, so they should not be propagated to the server. The server needs to be restarted in order to get a complete configuration.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-361) CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-361?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-533 to WFCORE-361:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-361 (was: WFLY-533)
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)
> CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-361
> URL: https://issues.jboss.org/browse/WFCORE-361
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Pavel Janousek
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as:
> {code}
> <server xmlns="urn:jboss:domain:1.3">
> {code}
> The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd.
> The very common Linux system has implemented and enabled dualstack in these days. If we instruct AS instance to bind to +any+ IPv4 address via {code}<interface name="public">
> <any-ipv4-address />
> </interface>{code}
> The real result is to bind running AS instance to +any+ IP address, not only in IPv4 address space but in IPv6 too!
> With default setting (= -Djava.net.preferIPv4Stack=true), result is correct - it is bound to ANY IPv4 addresses only.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[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)
11 years, 5 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)
11 years, 5 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)
11 years, 5 months