[JBoss JIRA] (WFLY-4321) restart of http connector without restarting whole web container
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4321?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved UNDERTOW-382 to WFLY-4321:
--------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-4321 (was: UNDERTOW-382)
Affects Version/s: 8.2.0.Final
(was: 1.2.0.Beta8)
Component/s: Web (Undertow)
(was: Core)
(was: SSL)
> restart of http connector without restarting whole web container
> ----------------------------------------------------------------
>
> Key: WFLY-4321
> URL: https://issues.jboss.org/browse/WFLY-4321
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Davide Gesino
> Assignee: Stuart Douglas
> Priority: Minor
> Labels: connector,, mbeans, ssl,
>
> It would be great if Undertow provided a feature Tomcat has, namely the possibility to stop the http connector without restarting the whole container.
> It's useful for example in case when certificates for SSL communication change while the container is up and running.
> Tomcat has this feature setting the property "org.apache.tomcat.util.ENABLE_MODELER" to true: this turn on the MBeans management for Tomcat.
> Through these beans it's possible to start and stop the connectors.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1910:
--------------------------------
OK, I'll take a look when I get to 3.6.2
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.2
>
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-estabilished, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1910:
---------------------------
Fix Version/s: 3.6.2
Can you show a concrete use case of this ? No logs, please, but a simple scenario with AB and CD for example
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.2
>
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-estabilished, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated JGRP-1910:
------------------------------
Attachment: SplitMergeTest.java
I can reproduce non-monotonous merges with this unit test. Enabling 10% data loss (on line 212) makes the issue more common.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-estabilished, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JGRP-1910:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1189839
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
>
> When connection between nodes is re-estabilished, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Radim Vansa (JIRA)
Radim Vansa created JGRP-1910:
---------------------------------
Summary: MERGE3: Do not lose any members from view during a series of merges
Key: JGRP-1910
URL: https://issues.jboss.org/browse/JGRP-1910
Project: JGroups
Issue Type: Bug
Reporter: Radim Vansa
Assignee: Bela Ban
When connection between nodes is re-estabilished, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4320) add->activate->remove->add->activate fails for Resource Adapter
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4320?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-4320:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1189715, https://bugzilla.redhat.com/show_bug.cgi?id=1189730 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1189715)
> add->activate->remove->add->activate fails for Resource Adapter
> ----------------------------------------------------------------
>
> Key: WFLY-4320
> URL: https://issues.jboss.org/browse/WFLY-4320
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.2.0.Final
> Reporter: Johnathon Lee
> Assignee: Stefano Maestri
>
> add->activate->remove->add->activate fails for Resource Adapter
> [1]
> [jolee@jolee540 jboss-eap-6.3.x]$ bin/jboss-cli.sh --connect
> [standalone@localhost:9999 /] deploy /home/jolee/amq.rar
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:activate
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:remove
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:activate
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.ra.deployment.amq is already registered",
> "rolled-back" => true
> }
> TRACE from failure
> 15:15:53,732 TRACE [org.jboss.as.connector.logging] (management-handler-thread - 10) ConnectorServices: getDeploymentServiceName(amq,<resource-adapter><archive>amq.rar</archive><transaction-support>XATransaction</transaction-support></resource-adapter>) -> service jboss.ra.deployment.amq
> 15:15:53,733 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) JBAS014612: Operation ("activate") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "amq")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.ra.deployment.amq is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:236) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:742) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:243) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2433) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:243) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2433) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:345) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.as.connector.util.RaServicesFactory.createDeploymentService(RaServicesFactory.java:104)
> at org.jboss.as.connector.subsystems.resourceadapters.RaOperationUtil.activate(RaOperationUtil.java:320)
> at org.jboss.as.connector.subsystems.resourceadapters.RaActivate$1.execute(RaActivate.java:57)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:611) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:489) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:290) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:285) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1132) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:251) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:152) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:203) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:132) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:149) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:396) [rt.jar:1.6.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:149) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) [jboss-as-protocol-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:537) [jboss-as-protocol-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4320) add->activate->remove->add->activate fails for Resource Adapter
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4320?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-4320:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1189715
> add->activate->remove->add->activate fails for Resource Adapter
> ----------------------------------------------------------------
>
> Key: WFLY-4320
> URL: https://issues.jboss.org/browse/WFLY-4320
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.2.0.Final
> Reporter: Johnathon Lee
> Assignee: Stefano Maestri
>
> add->activate->remove->add->activate fails for Resource Adapter
> [1]
> [jolee@jolee540 jboss-eap-6.3.x]$ bin/jboss-cli.sh --connect
> [standalone@localhost:9999 /] deploy /home/jolee/amq.rar
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:activate
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:remove
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=resource-adapters/resource-adapter=amq:activate
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.ra.deployment.amq is already registered",
> "rolled-back" => true
> }
> TRACE from failure
> 15:15:53,732 TRACE [org.jboss.as.connector.logging] (management-handler-thread - 10) ConnectorServices: getDeploymentServiceName(amq,<resource-adapter><archive>amq.rar</archive><transaction-support>XATransaction</transaction-support></resource-adapter>) -> service jboss.ra.deployment.amq
> 15:15:53,733 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) JBAS014612: Operation ("activate") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "amq")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.ra.deployment.amq is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:236) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:742) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:243) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2433) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:243) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2433) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:345) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.as.connector.util.RaServicesFactory.createDeploymentService(RaServicesFactory.java:104)
> at org.jboss.as.connector.subsystems.resourceadapters.RaOperationUtil.activate(RaOperationUtil.java:320)
> at org.jboss.as.connector.subsystems.resourceadapters.RaActivate$1.execute(RaActivate.java:57)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:611) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:489) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:290) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:285) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1132) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:251) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:152) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:203) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:132) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:149) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:396) [rt.jar:1.6.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:149) [jboss-as-controller-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) [jboss-as-protocol-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:537) [jboss-as-protocol-7.4.3.Final-redhat-SNAPSHOT.jar:7.4.3.Final-redhat-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months