[JBoss JIRA] (WFLY-9057) TimeoutException on second invocation of method with TransactionAttribute.MANDATORY (Stateful bean) within one transaction
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9057?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-11987 to WFLY-9057:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9057 (was: JBEAP-11987)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
EJB
Transactions
(was: Clustering)
(was: EJB)
(was: Transactions)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.ER1)
> TimeoutException on second invocation of method with TransactionAttribute.MANDATORY (Stateful bean) within one transaction
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9057
> URL: https://issues.jboss.org/browse/WFLY-9057
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Transactions
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> There is one server started with standalone-ha.xml profile (or there can be more servers in a cluster, it doesn't matter). There is a stateful bean [TransactionalBeanStateful.java|http://git.app.eng.bos.redhat.com/git/jbos...] provided in the deployment on the server.
> The bean has createPerson() method with TransactionAttributeType=MANDATORY.
> These steps lead to a TimeoutException:
> - client looks up a TransactionalBeanStateful bean,
> - client creates a UserTranscation:
> {code}
> final UserTransaction tx = (UserTransaction) ctx.lookup("txn:UserTransaction");
> {code}
> - client begins new transaction
> - client calls createPerson() method twice within the same transaction
> See steps to reproduce to reproduce the issue locally.
> Test code: http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree/ejb-...
> The issue does not occur if:
> - server is not started with *ha.xml profile
> - the bean is stateless
> Full stacktrace:
> {code}
> CLUSTER1_NODE1: 13:57:06,375 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component TransactionalBeanStateful for method public abstract void org.jboss.qa.ejb.tests.transactions.bean.TransactionalBeanRemote.createPerson(): javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UUIDSessionID [dbf99845-1e0f-4a5b-8b8a-0a81c16d1c0f] and requestor GlobalTransaction:<cluster1-node1>:5:local. Lock is held by GlobalTransaction:<cluster1-node1>:3:local
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:160)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.mandatory(CMTTxInterceptor.java:296)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:234)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:84)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ejb3.remote.AssociationImpl$$Lambda$1237/260509875.apply(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:479)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:474)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:182)
> at org.jboss.as.ejb3.remote.AssociationImpl$$Lambda$1234/1203786036.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UUIDSessionID [dbf99845-1e0f-4a5b-8b8a-0a81c16d1c0f] and requestor GlobalTransaction:<cluster1-node1>:5:local. Lock is held by GlobalTransaction:<cluster1-node1>:3:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:238)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:193)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:193)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:116)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:71)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:80)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:414)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:88)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:50)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:267)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:109)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255)
> ... 44 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2992) Can't restart domain master host with slave attached
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2992?page=com.atlassian.jira.plugi... ]
Ken Wills resolved WFCORE-2992.
-------------------------------
Resolution: Done
> Can't restart domain master host with slave attached
> ----------------------------------------------------
>
> Key: WFCORE-2992
> URL: https://issues.jboss.org/browse/WFCORE-2992
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta11
> Reporter: Matthew Casperson
> Assignee: Ken Wills
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
> Attachments: wildflydclogs.zip
>
>
> With a domain controller (whose management interface is configured with HTTPS) started on a host called master and no slaves attached, I can restart the host master with the command
> *./jboss-cli.ps1 --controller=remote+https://localhost:9993 -c --command="/host=master:shutdown(restart=true)"*
> over and over with no issues.
> Once a domain slave is attached, I often will not be able to restart the host master with the same command. It will shutdown, but not restart. The host master does seem to occasionally restart as expected, but not always.
> The output from the domain controller is this:
> {code:java}
> Registered remote slave host "desktop-p010d77", JBoss WildFly Full 11.0.0.Alpha1 (WildFly 3.0.0.Beta11)
> [Host Controller] 14:14:19,294 INFO [org.jboss.as.host.controller] (management-handler-thread - 1) WFLYHC0180: Shutting
> down in response to management operation 'shutdown'
> 14:14:19,300 INFO [org.jboss.as.process] (Thread-15) WFLYPC0017: Shutting down process controller
> 14:14:19,301 INFO [org.jboss.as.process.Host Controller.status] (Thread-15) WFLYPC0019: Stopping process 'Host Controll
> er'
> [Host Controller] 14:14:19,317 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-one
> [Host Controller] 14:14:19,320 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-two
> 14:14:19,320 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-one'
> 14:14:19,321 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-two'
> [Server:server-one] 14:14:19,322 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-two] 14:14:19,324 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-one] 14:14:19,343 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,351 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-5) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,354 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-one] 14:14:19,357 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,362 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,358 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-one] 14:14:19,360 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8443
> [Server:server-two] 14:14:19,367 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-3) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,364 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 67) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> [Server:server-two] 14:14:19,370 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-two] 14:14:19,372 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8593
> [Server:server-two] 14:14:19,374 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 35) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> [Server:server-one] 14:14:19,392 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-two] 14:14:19,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-two] 14:14:19,414 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-one] 14:14:19,426 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 74) AMQ151003: res
> ource adaptor stopped
> [Server:server-two] 14:14:19,437 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 73) AMQ151003: res
> ource adaptor stopped
> [Server:server-one] 14:14:19,475 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3d9fbbfb-5620-11e7-9672-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-one] 14:14:19,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-one] 14:14:19,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8080
> [Server:server-one] 14:14:19,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,488 INFO [org.jboss.as.host.controller] (management task-3) WFLYHC0027: Unregistering server
> server-one
> [Server:server-two] 14:14:19,491 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 73) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3da40166-5620-11e7-9b85-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-two] 14:14:19,493 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-two] 14:14:19,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8230
> [Server:server-two] 14:14:19,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,507 INFO [org.jboss.as.host.controller] (management task-5) WFLYHC0027: Unregistering server
> server-two
> [Server:server-one] 14:14:19,510 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 174ms
> [Server:server-two] 14:14:19,518 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 159ms
> 14:14:19,883 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'S
> erver:server-one' finished with an exit status of 0
> [Host Controller] 14:14:19,884 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-one
> 14:14:19,903 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'S
> erver:server-two' finished with an exit status of 0
> [Host Controller] 14:14:19,904 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-two
> [Host Controller] 14:14:19,906 WARN [org.jboss.as.domain.controller] (MSC service thread 1-1) WFLYHC0030: Connection to
> remote host "desktop-p010d77" closed unexpectedly
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2992) Can't restart domain master host with slave attached
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2992?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-2992:
-----------------------------------
I've tested this fairly extensively with the current wildfly-core on Windows and Linux, and I can't get the issue to reoccur. It's possible this was caused by one of the underlying shutdown issues we had previously.
The HC restarts correctly with the slave attached, and the slave reconnects, as expected.
> Can't restart domain master host with slave attached
> ----------------------------------------------------
>
> Key: WFCORE-2992
> URL: https://issues.jboss.org/browse/WFCORE-2992
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta11
> Reporter: Matthew Casperson
> Assignee: Ken Wills
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
> Attachments: wildflydclogs.zip
>
>
> With a domain controller (whose management interface is configured with HTTPS) started on a host called master and no slaves attached, I can restart the host master with the command
> *./jboss-cli.ps1 --controller=remote+https://localhost:9993 -c --command="/host=master:shutdown(restart=true)"*
> over and over with no issues.
> Once a domain slave is attached, I often will not be able to restart the host master with the same command. It will shutdown, but not restart. The host master does seem to occasionally restart as expected, but not always.
> The output from the domain controller is this:
> {code:java}
> Registered remote slave host "desktop-p010d77", JBoss WildFly Full 11.0.0.Alpha1 (WildFly 3.0.0.Beta11)
> [Host Controller] 14:14:19,294 INFO [org.jboss.as.host.controller] (management-handler-thread - 1) WFLYHC0180: Shutting
> down in response to management operation 'shutdown'
> 14:14:19,300 INFO [org.jboss.as.process] (Thread-15) WFLYPC0017: Shutting down process controller
> 14:14:19,301 INFO [org.jboss.as.process.Host Controller.status] (Thread-15) WFLYPC0019: Stopping process 'Host Controll
> er'
> [Host Controller] 14:14:19,317 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-one
> [Host Controller] 14:14:19,320 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-two
> 14:14:19,320 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-one'
> 14:14:19,321 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-two'
> [Server:server-one] 14:14:19,322 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-two] 14:14:19,324 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-one] 14:14:19,343 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,351 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-5) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,354 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-one] 14:14:19,357 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,362 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,358 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-one] 14:14:19,360 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8443
> [Server:server-two] 14:14:19,367 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-3) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,364 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 67) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> [Server:server-two] 14:14:19,370 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-two] 14:14:19,372 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8593
> [Server:server-two] 14:14:19,374 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 35) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> [Server:server-one] 14:14:19,392 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-two] 14:14:19,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-two] 14:14:19,414 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-one] 14:14:19,426 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 74) AMQ151003: res
> ource adaptor stopped
> [Server:server-two] 14:14:19,437 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 73) AMQ151003: res
> ource adaptor stopped
> [Server:server-one] 14:14:19,475 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3d9fbbfb-5620-11e7-9672-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-one] 14:14:19,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-one] 14:14:19,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8080
> [Server:server-one] 14:14:19,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,488 INFO [org.jboss.as.host.controller] (management task-3) WFLYHC0027: Unregistering server
> server-one
> [Server:server-two] 14:14:19,491 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 73) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3da40166-5620-11e7-9b85-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-two] 14:14:19,493 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-two] 14:14:19,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8230
> [Server:server-two] 14:14:19,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,507 INFO [org.jboss.as.host.controller] (management task-5) WFLYHC0027: Unregistering server
> server-two
> [Server:server-one] 14:14:19,510 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 174ms
> [Server:server-two] 14:14:19,518 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 159ms
> 14:14:19,883 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'S
> erver:server-one' finished with an exit status of 0
> [Host Controller] 14:14:19,884 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-one
> 14:14:19,903 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'S
> erver:server-two' finished with an exit status of 0
> [Host Controller] 14:14:19,904 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-two
> [Host Controller] 14:14:19,906 WARN [org.jboss.as.domain.controller] (MSC service thread 1-1) WFLYHC0030: Connection to
> remote host "desktop-p010d77" closed unexpectedly
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9056) Cannot add policy resource with no parameter
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9056?page=com.atlassian.jira.plugin.... ]
Claudio Miranda reassigned WFLY-9056:
-------------------------------------
Assignee: (was: Jason Greene)
> Cannot add policy resource with no parameter
> --------------------------------------------
>
> Key: WFLY-9056
> URL: https://issues.jboss.org/browse/WFLY-9056
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9056) Cannot add policy resource with no parameter
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9056?page=com.atlassian.jira.plugin.... ]
Claudio Miranda updated WFLY-9056:
----------------------------------
Component/s: Security
> Cannot add policy resource with no parameter
> --------------------------------------------
>
> Key: WFLY-9056
> URL: https://issues.jboss.org/browse/WFLY-9056
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Jason Greene
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
by Manuel Castro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1629?page=com.atlassian.jira.plugi... ]
Manuel Castro commented on DROOLS-1629:
---------------------------------------
Both issues are blocking the possibility to handle multiple Data Sources in the same project (using the same JPAPlaceholderResolverStrategy class implementation)
> PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1629
> URL: https://issues.jboss.org/browse/DROOLS-1629
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.4.0.Final, 6.5.0.Final, 7.0.0.Final
> Reporter: Manuel Castro
> Assignee: Mario Fusco
> Attachments: MultipleObjectMarshallingStrategiesOnContextWithSameClass.png
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.
> When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.
> The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.
> This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
> Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.
> In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
by Manuel Castro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1629?page=com.atlassian.jira.plugi... ]
Manuel Castro updated DROOLS-1629:
----------------------------------
Affects Version/s: 7.0.0.Final
> PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1629
> URL: https://issues.jboss.org/browse/DROOLS-1629
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.4.0.Final, 6.5.0.Final, 7.0.0.Final
> Reporter: Manuel Castro
> Assignee: Mario Fusco
> Attachments: MultipleObjectMarshallingStrategiesOnContextWithSameClass.png
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.
> When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.
> The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.
> This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
> Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.
> In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8851) Clean up managed domain handling of JSFImplListHandler
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8851?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-8851:
----------------------------------
I agree that allowing this op to get rolled out to the domain servers is the correct behaviour.
> Clean up managed domain handling of JSFImplListHandler
> ------------------------------------------------------
>
> Key: WFLY-8851
> URL: https://issues.jboss.org/browse/WFLY-8851
> Project: WildFly
> Issue Type: Sub-task
> Components: JSF
> Reporter: Brian Stansberry
> Assignee: Farah Juma
>
> Subtask for this item from the parent issue:
> {quote}
> The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is not the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
> a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
> b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
> d) We could just stop registering it on the profile, but that's a loss of functionality.
> Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
> {quote}
> The parent task is going to do choice b) as a temp thing; this task is decide about the rest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9056) Cannot add policy resource with no parameter
by Claudio Miranda (JIRA)
Claudio Miranda created WFLY-9056:
-------------------------------------
Summary: Cannot add policy resource with no parameter
Key: WFLY-9056
URL: https://issues.jboss.org/browse/WFLY-9056
Project: WildFly
Issue Type: Bug
Reporter: Claudio Miranda
Assignee: Jason Greene
subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
{code}
/profile=full/subsystem=elytron/policy=policy_test:add
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
"rolled-back" => true,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "failed",
"failure-description" => "Could find policy provider with name [policy_test]",
"rolled-back" => true
}}}}}}
}
{code}
To add is necessary to inform either custom-policy or jacc-policy
{code}
/profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
{
"outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}}}}}}
}
{code}
There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
by Manuel Castro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1629?page=com.atlassian.jira.plugi... ]
Manuel Castro updated DROOLS-1629:
----------------------------------
Attachment: MultipleObjectMarshallingStrategiesOnContextWithSameClass.png
> PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1629
> URL: https://issues.jboss.org/browse/DROOLS-1629
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.4.0.Final, 6.5.0.Final
> Reporter: Manuel Castro
> Assignee: Mario Fusco
> Attachments: MultipleObjectMarshallingStrategiesOnContextWithSameClass.png
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.
> When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.
> The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.
> This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
> Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.
> In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months