[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5021:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163665
> Nodes that finish the rebalance later can see outdated values
> -------------------------------------------------------------
>
> Key: ISPN-5021
> URL: https://issues.jboss.org/browse/ISPN-5021
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Beta1
>
>
> Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...]
> If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help.
> I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4444) After state transfer, a node is able to read keys it no longer owns from its data container
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4444?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4444:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1163665|https://bugzilla.redhat.com/show_bug.cgi?id=1163665] from ON_QA to ASSIGNED
> After state transfer, a node is able to read keys it no longer owns from its data container
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-4444
> URL: https://issues.jboss.org/browse/ISPN-4444
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> When state transfer ends and each node receives a CH_UPDATE command from the coordinator, it first installs the new topology and then it starts invalidating entries it no longer owns.
> However, there are two cases when the node can still read its stale values:
> 1. If L1 is enabled, it will look in the local DataContainer first, regardless of the key's location.
> 2. If L1 is disabled, but the key was removed on the new owners, the node will still look up the key in the local DataContainer after receiving a null response.
> The problem can be reproduced with {{TxReadAfterLosingOwnershipTest}} and its subclasses, by replacing the {{operation.update(cache(1));}} line with {{operation.update(cache(0));}}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-5059:
----------------------------------
Summary: JGroups subsystem doesn't support Vault (was: JGroups subsystem doesn't support with Vault)
> JGroups subsystem doesn't support Vault
> ---------------------------------------
>
> Key: ISPN-5059
> URL: https://issues.jboss.org/browse/ISPN-5059
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Reporter: Vojtech Juranek
>
> JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
> {noformat}
> <protocol type="ENCRYPT">
> <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
> <property name="store_password">${VAULT::keystore::password::1}</property>
> <property name="alias">memcached</property>
> </protocol>
> {noformat}
> i.e. it uses Vault-encrypted password for keystore, it fails with:
> {noformat}
> groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
> at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:848)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
> {noformat}
> Vault record for {{keystore::password}} exists:
> {noformat}
> Task: Verify whether a secured attribute exists
> Enter Vault Block:keystore
> Enter Attribute Name:password
> A value exists for (keystore, password)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support with Vault
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5059:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1172038
> JGroups subsystem doesn't support with Vault
> --------------------------------------------
>
> Key: ISPN-5059
> URL: https://issues.jboss.org/browse/ISPN-5059
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Reporter: Vojtech Juranek
>
> JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
> {noformat}
> <protocol type="ENCRYPT">
> <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
> <property name="store_password">${VAULT::keystore::password::1}</property>
> <property name="alias">memcached</property>
> </protocol>
> {noformat}
> i.e. it uses Vault-encrypted password for keystore, it fails with:
> {noformat}
> groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
> at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:848)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
> {noformat}
> Vault record for {{keystore::password}} exists:
> {noformat}
> Task: Verify whether a secured attribute exists
> Enter Vault Block:keystore
> Enter Attribute Name:password
> A value exists for (keystore, password)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support with Vault
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-5059:
----------------------------------
Summary: JGroups subsystem doesn't support with Vault (was: JGroups subsystem doesn't work with Vault)
> JGroups subsystem doesn't support with Vault
> --------------------------------------------
>
> Key: ISPN-5059
> URL: https://issues.jboss.org/browse/ISPN-5059
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Reporter: Vojtech Juranek
>
> JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
> {noformat}
> <protocol type="ENCRYPT">
> <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
> <property name="store_password">${VAULT::keystore::password::1}</property>
> <property name="alias">memcached</property>
> </protocol>
> {noformat}
> i.e. it uses Vault-encrypted password for keystore, it fails with:
> {noformat}
> groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
> at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:848)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
> {noformat}
> Vault record for {{keystore::password}} exists:
> {noformat}
> Task: Verify whether a secured attribute exists
> Enter Vault Block:keystore
> Enter Attribute Name:password
> A value exists for (keystore, password)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5060) PartitionHandling: remove unavailable mode
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5060:
----------------------------------
Summary: PartitionHandling: remove unavailable mode
Key: ISPN-5060
URL: https://issues.jboss.org/browse/ISPN-5060
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 7.1.0.Alpha1, 7.0.2.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 7.1.0.Final
The Unavailable mode name is misleading, because some keys are available, just like in Degraded mode.
The only difference between Degraded and Unavailable is that with Degraded the cluster might recover without manual intervention. The administrator still has to know a lot more details in order to decide whether manual intervention is needed or not. So it would be less confusing if gracefully shutting down {{numOwners}} nodes in quick succession would leave the cache in Degraded mode instead of Unavailable.
Instead of removing the Unavailable mode completely, we could also change it to deny access to all the keys and allow the administrator to use it. E.g. if we had an operation to dump the cache into a shared store and another to load the cache from a shared store, the administrator could force the cache into Unavailable mode while dumping/loading the cache.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't work with Vault
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-5059:
-------------------------------------
Summary: JGroups subsystem doesn't work with Vault
Key: ISPN-5059
URL: https://issues.jboss.org/browse/ISPN-5059
Project: Infinispan
Issue Type: Bug
Components: Security, Server
Reporter: Vojtech Juranek
JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
{noformat}
<protocol type="ENCRYPT">
<property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
<property name="store_password">${VAULT::keystore::password::1}</property>
<property name="alias">memcached</property>
</protocol>
{noformat}
i.e. it uses Vault-encrypted password for keystore, it fails with:
{noformat}
groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
at org.jgroups.JChannel.init(JChannel.java:848)
at org.jgroups.JChannel.<init>(JChannel.java:159)
at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
{noformat}
Vault record for {{keystore::password}} exists:
{noformat}
Task: Verify whether a secured attribute exists
Enter Vault Block:keystore
Enter Attribute Name:password
A value exists for (keystore, password)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4975) Cross site state transfer - status of push gets stuck at "SENDING" after being cancelled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4975?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4975:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1163337|https://bugzilla.redhat.com/show_bug.cgi?id=1163337] from ON_QA to VERIFIED
> Cross site state transfer - status of push gets stuck at "SENDING" after being cancelled
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-4975
> URL: https://issues.jboss.org/browse/ISPN-4975
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Alpha1
>
>
> After invoking: site --cancelpush backupSite on the producer site, status of the push operation seems to get stuck at "SENDING" value (tested by site --pushstatus), even if state transfer is not currently in progress.
> Invoking site --cancelreceive mainSite on the consumer site works correctly. New invocation of site --push backupsite leads to "X-Site state transfer to '%s' already started!" being displayed. The issue seems to be caused by XSiteStateTransferManagerImpl.siteCollector not being cleared.
> Used configuration:
> distributed caches, site A: 2 nodes, site B: 3 nodes, B is a backup for A.
> Scenario
> - Start A,B
> - Take B offline using takeSiteOffline
> - Load data into A
> - Push state into B
> - CancelPushState B
> -- PushStateStatus remains stuck at SENDING & new push is not possible
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4974) Cross site state transfer - CLI ops throw NPE when backup is not defined
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4974?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4974:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1163332|https://bugzilla.redhat.com/show_bug.cgi?id=1163332] from ON_QA to VERIFIED
> Cross site state transfer - CLI ops throw NPE when backup is not defined
> ------------------------------------------------------------------------
>
> Key: ISPN-4974
> URL: https://issues.jboss.org/browse/ISPN-4974
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.0.0.Final
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Alpha1, 7.1.0.Final
>
>
> When <backups><backup site="XYZ"/></backups> is not present in configuration of given cache, "site" CLI operations are still available on the node. However, their usage leads to NPEs being thrown, e.g.
> [31m22:40:13,381 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 4) ISPN019003: Interpreter error: java.lang.NullPointerException
> at org.infinispan.cli.interpreter.statement.SiteStatement.execute(SiteStatement.java:46) [infinispan-cli-interpreter-7.0.0.Final.jar:7.0.0.Final]
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:149) [infinispan-cli-interpreter-7.0.0.Final.jar:7.0.0.Final]
> at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:255) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final]
> at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:252) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final]
> at org.infinispan.security.Security.doPrivileged(Security.java:89) [infinispan-core-7.0.0.Final.jar:7.0.0.Final]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:68) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final]
> at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:258) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:49) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_60]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months