[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
11 years
[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
11 years
[JBoss JIRA] (WFLY-2090) CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2090:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-2090
> URL: https://issues.jboss.org/browse/WFLY-2090
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 8.0.0.CR1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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
11 years
[JBoss JIRA] (WFLY-2088) Error creating server group as scoped role user
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2088:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Error creating server group as scoped role user
> -----------------------------------------------
>
> Key: WFLY-2088
> URL: https://issues.jboss.org/browse/WFLY-2088
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> I've got a scoped role
> {noformat}
> [domain@localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
> "outcome" => "success",
> "result" => {
> "base-role" => "MAINTAINER",
> "server-groups" => ["main-server-group"]
> }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain@localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
> "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
11 years
[JBoss JIRA] (WFLY-2085) Prevent server group scoped roles modifying the master HC if it has no servers
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2085?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2085:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Prevent server group scoped roles modifying the master HC if it has no servers
> ------------------------------------------------------------------------------
>
> Key: WFLY-2085
> URL: https://issues.jboss.org/browse/WFLY-2085
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.CR1
>
>
> Currently server group scoped roles with write or security-sensitive-read privileges are able to use those privileges with any HC that has no servers defined. This allows the role to do things like add a server in the group to a newly spun up host.
> The master HC should be excluded from this ability. The master would typically not have servers, but not because it is a newly spun-up host.
--
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
11 years
[JBoss JIRA] (WFLY-2055) Centralize and organize I/O-related options into I/O subsystem
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2055?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2055:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Centralize and organize I/O-related options into I/O subsystem
> --------------------------------------------------------------
>
> Key: WFLY-2055
> URL: https://issues.jboss.org/browse/WFLY-2055
> Project: WildFly
> Issue Type: Enhancement
> Components: Remoting, Web (Undertow)
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Centralize all the I/O related options into the I/O subsystem schema. This includes all XNIO Options, and also includes moving all XNIO worker configuration into the I/O subsystem to be referenced.
> The I/O subsystem should define types for each I/O option including (but not limited to):
> * send and receive buffer sizes
> * TCP nodelay setting
> * TCP keepalive
> * IP TOS
> * Server socket backlog
> * Server connection limit low/high water mark
> * etc.
> Also there should be types defined for:
> * XNIO worker thread count
> * XNIO worker thread stack size
> * XNIO worker thread priority
> * etc.
> Systems which define I/O entities will reference these types by including the allowed/relevant option types into their schema like the threads subsystem does for thread pool types.
> Systems presently defining workers should instead reference a worker defined in the I/O subsystem.
--
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
11 years
[JBoss JIRA] (WFLY-2145) Automatically add XTS and TXBridge handlers to Web Services that use JTA annotations
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2145?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2145:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Automatically add XTS and TXBridge handlers to Web Services that use JTA annotations
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2145
> URL: https://issues.jboss.org/browse/WFLY-2145
> Project: WildFly
> Issue Type: Enhancement
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 8.0.0.CR1
>
>
> Currently the developer needs to specify the XTS and Bridge handlers on the Web Service that wishes inflow a WS-AT transaction. This is cumbersome and error prone.
> It is quite easy to infer if the user needs these handlers by checking to see if the Web Service uses @Transactional or @TransactionAtttibute and by looking for a WS-AT transaction context on the inbound message.
> The same can also be done for the Compensations API, by looking for @Compensatable annotations on the Web Service. In which case, only the XTS handler should be added as no bridging is required.
--
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
11 years