[JBoss JIRA] (WFLY-1577) Deployment error
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-1577?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-1577.
---------------------------------------
Assignee: Emanuel Muckenhuber (was: Brian Stansberry)
Resolution: Rejected
I am rejecting this issue, because we do not want to change the behavior of missing deployments contents. This should only happen when you manually remove the contents from the repository, which is not a valid use case.
There however was a related issue which probably lead to this problem in the first place:
https://issues.jboss.org/browse/WFLY-2420
> Deployment error
> ----------------
>
> Key: WFLY-1577
> URL: https://issues.jboss.org/browse/WFLY-1577
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Emanuel Muckenhuber
>
> [Host Controller] 15:09:15,993 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) Operation ("add") failed - address: ([("deployment" => "jboss-as-helloworld-mdb.war")]) - failure description: "JBAS010876: No deployment content with hash 7ba3e87a0079895f0aad95c16739b513fd5a28d8 is available in the deployment content repository for deployment 'jboss-as-helloworld-mdb.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
--
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, 2 months
[JBoss JIRA] (WFLY-479) Ability to rollback AS version updates
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-479?page=com.atlassian.jira.plugin.s... ]
Emanuel Muckenhuber resolved WFLY-479.
--------------------------------------
Assignee: Emanuel Muckenhuber
Resolution: Done
This is covered by the patching mechanism.
> Ability to rollback AS version updates
> --------------------------------------
>
> Key: WFLY-479
> URL: https://issues.jboss.org/browse/WFLY-479
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> A fixpack installer that handles version rollbacks would be fantastic.
> >> Of course it needs to remain flexible to work with JBoss installs that
> >> have been manually modified.
> Note that this may be out of scope for community AS 7; e.g. it may be a JON function. However, the AS 7 design of things like how we lay down content on the filesystem should take this use case into account.
--
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, 2 months
[JBoss JIRA] (WFLY-2495) ContainerXFilter not invoked when registered via DynamicFeature in JAX-RS
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2495?page=com.atlassian.jira.plugin.... ]
Aslak Knutsen commented on WFLY-2495:
-------------------------------------
Same behavior on 8.0.0.Beta2-SNAPSHOT, current master.
> ContainerXFilter not invoked when registered via DynamicFeature in JAX-RS
> -------------------------------------------------------------------------
>
> Key: WFLY-2495
> URL: https://issues.jboss.org/browse/WFLY-2495
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Beta1
> Reporter: Aslak Knutsen
> Assignee: Stuart Douglas
>
> {code}
> @Provider
> public class DynamicServerLogggingFilterFeature implements DynamicFeature {
> @Override
> public void configure(ResourceInfo ri, FeatureContext fc) {
> if (MyResource.class.isAssignableFrom(ri.getResourceClass())
> && ri.getResourceMethod().isAnnotationPresent(GET.class)) {
> fc.register(new ServerLoggingFilter());
> }
> }
> }
> @Provider
> @ServerLogged
> public class ServerLoggingFilter implements ContainerRequestFilter, ContainerResponseFilter {
> ...
> }
> {code}
> DynamicServerLogggingFilterFeature is called the the ServerLoggingFilter is registered in the FeatureContext, but the filter(ContainerXContext crc) is never called on the ServerLoggingFilter.
> Sample: https://github.com/arun-gupta/javaee7-samples/tree/master/jaxrs/dynamicfi...
--
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, 2 months
[JBoss JIRA] (JGRP-1737) TP: ignore DONT_BUNDLE flag for sending of messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1737?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1737 at 11/12/13 10:20 AM:
-----------------------------------------------------------
Used UPerf to benchmark this on cluster01-04 (4 nodes, fast.xml with ip_tl=1):
|| Bundling enabled (master) || Bundling enabled (JGRP-1737) || Bundling disabled (master) || Bundling disabled (JGRP-1737) ||
| 27'127 | 28'105 | 22'863 | *26'106* |
The numbers for bundling are about the same (fluctuations do occur as others are using this cluster, too). However, the number for bundling disabled ({{+DONT_BUNDLE}}) goes up from 22'836 to 26'106. This is the case because now even messages with the {{DONT_BUNDLE}} flag set are bundled.
was (Author: belaban):
Used UPerf to benchmark this on cluster01-04 (4 nodes, fast.xml with ip_tl=1):
|| Bundling enabled (master) || Bundling enabled (JGRP-1737) || Bundling disabled (master) || Bundling disabled (JGRP-1737) ||
| 27'127 | 28'105 | 22'863 | 26'106 |
The numbers for bundling are about the same (fluctuations do occur as others are using this cluster, too). However, the number for bundling disabled ({{+DONT_BUNDLE}}) go up from 22'836 to 26'106. This is the case because now even messages with the {{DONT_BUNDLE}} flag set are bundled.
> TP: ignore DONT_BUNDLE flag for sending of messages
> ---------------------------------------------------
>
> Key: JGRP-1737
> URL: https://issues.jboss.org/browse/JGRP-1737
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, messages tagged with DONT_BUNDLE are sent separately, not as a message bundle through a bundler. On the receiver, they are passed up as single messages, ie. on a separate thread.
> Sending a lot of single (possibly small) messages is inefficient; it would be better to bundle *all* message on the sender side. This requires a bundler which sends single messages immediately when no other messages are available to be sent.
> SOLUTION (sender):
> * If the bundler is *not* "old", ignore the DONT_BUNDLE flag and send the message through the bundler
> * Else, same as now; send the message immediately as single message
> SOLUTION (receiver):
> * When reading the message list and creating the 4 batches (regular, oob, oob+internal, internal), if a message has DONT_BUNDLE set, pass it as single message to the corresponding thread pool and don't add it to the batch
> This has the advantage that we have a more efficient way of sending messages (as message bundles), yet the behavior (and performance) at the receiver is the same as now
--
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, 2 months
[JBoss JIRA] (WFLY-2495) ContainerXFilter not invoked when registered via DynamicFeature in JAX-RS
by Aslak Knutsen (JIRA)
Aslak Knutsen created WFLY-2495:
-----------------------------------
Summary: ContainerXFilter not invoked when registered via DynamicFeature in JAX-RS
Key: WFLY-2495
URL: https://issues.jboss.org/browse/WFLY-2495
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: REST
Affects Versions: 8.0.0.Beta1
Reporter: Aslak Knutsen
Assignee: Stuart Douglas
{code}
@Provider
public class DynamicServerLogggingFilterFeature implements DynamicFeature {
@Override
public void configure(ResourceInfo ri, FeatureContext fc) {
if (MyResource.class.isAssignableFrom(ri.getResourceClass())
&& ri.getResourceMethod().isAnnotationPresent(GET.class)) {
fc.register(new ServerLoggingFilter());
}
}
}
@Provider
@ServerLogged
public class ServerLoggingFilter implements ContainerRequestFilter, ContainerResponseFilter {
...
}
{code}
DynamicServerLogggingFilterFeature is called the the ServerLoggingFilter is registered in the FeatureContext, but the filter(ContainerXContext crc) is never called on the ServerLoggingFilter.
Sample: https://github.com/arun-gupta/javaee7-samples/tree/master/jaxrs/dynamicfi...
--
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, 2 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Emanuel Muckenhuber <emuckenh(a)redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from ASSIGNED to POST
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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, 2 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862]
I'm proposing a blocker. This is big.
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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, 2 months
[JBoss JIRA] (JGRP-1737) TP: ignore DONT_BUNDLE flag for sending of messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1737?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1737:
--------------------------------
Used UPerf to benchmark this on cluster01-04 (4 nodes, fast.xml with ip_tl=1):
|| Bundling enabled (master) || Bundling enabled (JGRP-1737) || Bundling disabled (master) || Bundling disabled (JGRP-1737) ||
| 27'127 | 28'105 | 22'863 | 26'106 |
The numbers for bundling are about the same (fluctuations do occur as others are using this cluster, too). However, the number for bundling disabled ({{+DONT_BUNDLE}}) go up from 22'836 to 26'106. This is the case because now even messages with the {{DONT_BUNDLE}} flag set are bundled.
> TP: ignore DONT_BUNDLE flag for sending of messages
> ---------------------------------------------------
>
> Key: JGRP-1737
> URL: https://issues.jboss.org/browse/JGRP-1737
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, messages tagged with DONT_BUNDLE are sent separately, not as a message bundle through a bundler. On the receiver, they are passed up as single messages, ie. on a separate thread.
> Sending a lot of single (possibly small) messages is inefficient; it would be better to bundle *all* message on the sender side. This requires a bundler which sends single messages immediately when no other messages are available to be sent.
> SOLUTION (sender):
> * If the bundler is *not* "old", ignore the DONT_BUNDLE flag and send the message through the bundler
> * Else, same as now; send the message immediately as single message
> SOLUTION (receiver):
> * When reading the message list and creating the 4 batches (regular, oob, oob+internal, internal), if a message has DONT_BUNDLE set, pass it as single message to the corresponding thread pool and don't add it to the batch
> This has the advantage that we have a more efficient way of sending messages (as message bundles), yet the behavior (and performance) at the receiver is the same as now
--
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, 2 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from VERIFIED to ASSIGNED
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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, 2 months