[JBoss JIRA] (WFLY-1306) EJB session creation frequently fails with SuspectedException javax.transaction.RollbackException: Exception rolled back, status is: 9
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1306?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1306:
-----------------------------------------------
Jaikiran Pai <jpai(a)redhat.com> changed the Status of [bug 957171|https://bugzilla.redhat.com/show_bug.cgi?id=957171] from ASSIGNED to POST
> EJB session creation frequently fails with SuspectedException javax.transaction.RollbackException: Exception rolled back, status is: 9
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1306
> URL: https://issues.jboss.org/browse/WFLY-1306
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: jaikiran pai
> Assignee: Paul Ferraro
> Attachments: log.txt
>
>
> I've a testcase which has the following flow:
> 1) Start 2 servers (node0 and node1)in clustered mode (standalone-ha.xml)
> 2) deploy a deployment to the servers contains the same SFSB which is marked as @Clustered. The SFSB has a @PreDestroy which intentionally does a Thread.sleep to slow down the undeployment process (whenever it happens)
> 3) Keep doing lookups for the SFSB from a remote client, which essentially translates into session creation on the servers
> 4) While #3 is happening, undeploy the application from node0. Since the SFSB has a Thread.sleep, the undeployment takes some time to actually finish.
> 5) In the meantime, the session creation requests from the remote client happen on the other functional node (node1) but after a while, node1 starts throwing the following exception:
> {code}
> 17:05:23,505 ERROR [org.infinispan.transaction.TransactionCoordinator] (EJB default - 7) Error while processing prepare: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-0/ejb was suspected
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:184)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:247)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:234)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:229)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:208)
> at org.infinispan.interceptors.ReplicationInterceptor.broadcastPrepare(ReplicationInterceptor.java:109)
> at org.infinispan.interceptors.ReplicationInterceptor.visitPrepareCommand(ReplicationInterceptor.java:101)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:106)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:108)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:135)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:58)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:128)
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:115)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:61)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:189)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:93)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:141)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
> at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
> at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
> at org.infinispan.CacheImpl.endBatch(CacheImpl.java:684)
> at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
> at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:53)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:81)
> at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.insert(InfinispanBackingCacheEntryStore.java:176)
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:304)
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:51)
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.create(PassivatingBackingCacheImpl.java:122)
> at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:67)
> at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:41)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:146)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_15]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
> 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]
> Caused by: SuspectedException
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:377)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> ... 93 more
> 17:05:23,515 ERROR [org.infinispan.transaction.tm.DummyTransaction] (EJB default - 7) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=3, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction@4f} org.infinispan.transaction.synchronization.SynchronizationAdapter@6e: org.infinispan.CacheException: Could not prepare.
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
> at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
> at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
> at org.infinispan.CacheImpl.endBatch(CacheImpl.java:684)
> at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
> at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:53)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:81)
> at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.insert(InfinispanBackingCacheEntryStore.java:176)
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:304)
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.insert(SerializationGroupMemberContainer.java:51)
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.create(PassivatingBackingCacheImpl.java:122)
> at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:67)
> at org.jboss.as.ejb3.cache.impl.GroupAwareCache.create(GroupAwareCache.java:41)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:146)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_15]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
> 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]
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
> ... 26 more
> {code}
> This causes the session creation to fail on node1 (which was expected to be functional).
> The entire relevant log is attached.
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-1308) EJB invocation from a remote client when the deployment is being undeployed doesn't trigger a retry on a different node
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1308?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1308:
-----------------------------------------------
Jaikiran Pai <jpai(a)redhat.com> changed the Status of [bug 957171|https://bugzilla.redhat.com/show_bug.cgi?id=957171] from ASSIGNED to POST
> EJB invocation from a remote client when the deployment is being undeployed doesn't trigger a retry on a different node
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1308
> URL: https://issues.jboss.org/browse/WFLY-1308
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: jaikiran pai
> Assignee: jaikiran pai
>
> Consider the following case:
> 1) Same bean deployed on a server A and server B
> 2) Remote EJB client which is aware of both server A and server B, in its EJBClientContext, invokes on the bean
> 3) EJB client API selects server A as the target node and lets it handle it.
> 4) In the meantime, after the request has been sent, but before it has been handled on the server A, the deployment on server A is triggered for undeployment.
> 5) This causes the EJB component on server A to throw an exception telling the client that the bean is in shutdown mode and no more invocations are accepted.
> The exception thrown in #5 should really trigger a retry of the invocation, from the client side, on other eligible nodes (in this case Server B), because this failure is as good as the bean not being available in first place on Server A.
> Currently, the client isn't retrying the invocation on a different node, because it has no idea that this specific exception is no different than other potential exceptions that can be thrown by the server for a EJB invocation. To fix this, the method invocation handler on the server side should send back a "no such bean" message to the client, when the server sees that the bean is in shutdown mode.
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-179) CLONE - Adding modcluster via the CLI fails.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-179?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-179:
----------------------------------------------
Aleksandar Kostadinov <akostadi(a)redhat.com> made a comment on [bug 900801|https://bugzilla.redhat.com/show_bug.cgi?id=900801]
I am running EAP 6.0.1 ER5 in *domain* mode. And there seems to be no way to add mod_cluster through cli while there are running servers.
Foremost composite operation does not seem to work at all. Any composite operation I try to execute results in:
> Operation 'composite' does not expect any property.
This command has worked with EAP 6.0.1 but is *not* working now. This is a *regression*:
> /:composite(steps=[ {"operation" => "add", "address" => [ ("profile" => "default"), ("subsystem" => "modcluster") ] },{ "operation" => "add", "address" => [ ("profile" => "default"), ("subsystem" => "modcluster"), ("mod-cluster-config" => "configuration") ], "advertise" => "false", "proxy-list" => "${jboss.modcluster.proxyList}", "connector" => "ajp"}, { "operation" => "add", "address" => [ ("profile" => "default"), ("subsystem" => "modcluster"), ("mod-cluster-config" => "configuration"), ("dynamic-load-provider" => "configuration") ]}, { "operation" => "add", "address" => [ ("profile" => "default"), ("subsystem" => "modcluster"), ("mod-cluster-config" => "configuration"), ("dynamic-load-provider" => "configuration"), ("load-metric" => "busyness")], "type" => "busyness"} ])
> Operation 'composite' does not expect any property.
Trying with normal commands I'm getting the famous "connector may not be null"
> /profile=default/subsystem=modcluster:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"ip-10-0-254-48" => {
> "server-one" => {"response" => {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014746: connector may not be null",
> "rolled-back" => true
> }},
> "server-two" => {"response" => {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014746: connector may not be null",
> "rolled-back" => true
> }}
> }}}}
> }
The same command works only if server-one and server-two both are stopped. The composite command does not start working though.
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
> Key: WFLY-179
> URL: https://issues.jboss.org/browse/WFLY-179
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Clustering
> Reporter: Tom Fonteyne
> Assignee: Radoslav Husar
> Fix For: 8.0.0.Alpha1
>
>
> Adding modcluster via the CLI fails.
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne commented on WFLY-1309:
------------------------------------
domain.xml unchanged indeed.
host.xml both attached. They are out of the box, except:
- DC: removed the <servers>
- slave: pointed to DC + secret, and removed the <servers>
I run on two physical VM's btw, as is the customer
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"test\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-1309:
-------------------------------
Attachment: host-slave.xml
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"test\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-1309:
-------------------------------
Attachment: host-domain-controller.xml
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Attachments: host-domain-controller.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"test\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1309:
----------------------------------------
To be more specific, I'd like to see the files as they looked *before* you began the CLI operations you described.
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"test\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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
13 years, 2 months
[JBoss JIRA] (WFLY-509) JSR-343 JMS 2.0 Support
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-509?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins edited comment on WFLY-509 at 5/2/13 7:52 PM:
--------------------------------------------------------------
Does this JIRA includes the work wrt doing the parsing of annotations and doing the bindings for jms connection factories and jms destinations (EE 7 5.18.4 & 5.18.5)?
Integrated on this JIRA or not, if you need a hand on that, please create JIRA and assign it to me. JBoss Metadata 8 Alpha 3 supports these already.
was (Author: emmartins):
Does this JIRA includes the work wrt doing the parsing of annotations and doing the bindings for jms connection factories and jms destinations (EE 7 5.18.4 & 5.18.5)?
> JSR-343 JMS 2.0 Support
> -----------------------
>
> Key: WFLY-509
> URL: https://issues.jboss.org/browse/WFLY-509
> Project: WildFly
> Issue Type: Sub-task
> Components: JMS
> Reporter: David Lloyd
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha1
>
>
> Add support for JMS 2.0 as per Java EE 7 specification.
--
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
13 years, 2 months