[JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does not work on MacOS
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1928:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
> Key: WFLY-1928
> URL: https://issues.jboss.org/browse/WFLY-1928
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Alpha4
> Reporter: Thomas Diesler
> Assignee: jaikiran pai
> Fix For: 8.0.0.CR1
>
>
> {code}
> FuseFabric:karaf@root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-1955) Failed to read hosts
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1955?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1955:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Failed to read hosts
> --------------------
>
> Key: WFLY-1955
> URL: https://issues.jboss.org/browse/WFLY-1955
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Heiko Braun
> Labels: eap6.x
> Fix For: 8.0.0.CR1
>
> Attachments: WFLY-1955-reproduce.txt
>
>
> Steps top reproduce:
> 1) Start domain
> 2) set server into reload state (transactions > statistics=true)
> 3) stop server from CLI (or web console)
> 4) execute CLI command:
> {noformat}
> [domain@localhost:9999 /] :read-children-resources(child-type=host)
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is not found
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2004?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2004:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
> Key: WFLY-2004
> URL: https://issues.jboss.org/browse/WFLY-2004
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Logging
> Reporter: Heiko Braun
> Assignee: James Perkins
> Fix For: 8.0.0.CR1
>
> Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1] ("subsystem" => "logging"),
> [Server:stage1] ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-1966) Hangs in DomainControllerMigrationTestCase
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1966?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1966:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Hangs in DomainControllerMigrationTestCase
> ------------------------------------------
>
> Key: WFLY-1966
> URL: https://issues.jboss.org/browse/WFLY-1966
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 8.0.0.CR1
>
> Attachments: thread-dump.txt
>
>
> DomainControllerMigrationTestCase is intermittently hanging recently.
> I will attach thread dumps from a recent hang.
> The test driver is hanging here:
> "main" prio=10 tid=0xb7605c00 nid=0x7656 in Object.wait() [0xb7786000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa99833f8> (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)
> - eliminated <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xa99833f8> (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:76)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:86)
> at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.executeForResult(DomainLifecycleUtil.java:580)
> at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:206)
> The master HC process is stuck here:
> "management-handler-thread - 2" prio=10 tid=0x8be50400 nid=0x1a92 waiting on condition [0x87604000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xaa032fd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at org.jboss.as.controller.remote.BlockingQueueOperationListener.retrievePreparedOperation(BlockingQueueOperationListener.java:84)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.execute(DomainSlaveHandler.java:117)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> I see nothing relevant in the other thread dumps.
> The master HC is blocking waiting for a response from the slave HC.
> Just before the client makes the request that triggers this, it has reloaded the slave HC. The test is not robust in terms of how it checks that the slave is ready before continuing on with the test; it merely connects directly to the slave checks that the slave's root resource can be read. That can succeed relatively early in boot even before the slave has registered with the master.
> Fixing that may prevent the hangs, but it would likely paper over whatever problem is causing the hangs. A client invoking multi-host operations while a slave is booting and registering is a use case that can't hang.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2112) Test that validate-address and validate-operation do not leak non-addressable addresses
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2112?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2112:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Test that validate-address and validate-operation do not leak non-addressable addresses
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2112
> URL: https://issues.jboss.org/browse/WFLY-2112
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Ladislav Thon
> Fix For: 8.0.0.CR1
>
>
> basically those operations check that an address is valid, or that an operation is valid
> 14:18
> the operation has an address
> 14:18
> So you do :validate-address(value="/some=where")
> 14:18
> I made up the syntax for the value thing, it needs a ModelNode
> 14:19 bstans_afk
> Ladicek: the CLI uses that behind the scenes
> 14:19 kkhan
> So the way it worked until now is that if the address is valid, it returns that it is valid
> 14:19
> and if it is not valid it returns that it is not valid
> 14:20 Ladicek
> wow, never heard of that
> 14:20 kkhan
> however, if /some=where is not addressable for the current user, we want to return that it is invalid
> 14:20 Ladicek
> souns sensible to me
> 14:20 kkhan
> i.e. to hide the non-addressable addresses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months