[JBoss JIRA] (SWSQE-524) Checker Not Checking For Traffice Unless Skip-Checker Stage Is Run
by Matt Mahoney (Jira)
Matt Mahoney created SWSQE-524:
----------------------------------
Summary: Checker Not Checking For Traffice Unless Skip-Checker Stage Is Run
Key: SWSQE-524
URL: https://issues.jboss.org/browse/SWSQE-524
Project: Kiali QE
Issue Type: Bug
Reporter: Matt Mahoney
Assignee: Michael Foley
The Checker job should validate Bookinfo Traffic every time that the traffic generator is deployed for the Bookinfo/Bookinfo2 meshes.
Currently the only time that Bookinfo Traffic is checked is when the Skip-Checker phase is run.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11380) Extending MDB validation to all EJB
by Romain Pelisse (Jira)
Romain Pelisse created WFLY-11380:
-------------------------------------
Summary: Extending MDB validation to all EJB
Key: WFLY-11380
URL: https://issues.jboss.org/browse/WFLY-11380
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: Romain Pelisse
Assignee: Romain Pelisse
WFLY-10048 introduced some code changes to ensure that MDB being deployed follows the EJB specification guidelines. This validation should be extended to cover all kind of EJBs and not only MDBs.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11142) Regression in SOAP over JMS when WF13 and WF14 are communicating
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11142?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-11142:
-----------------------------------
[~jmesnil] [~jbliznak] as WFLY-11143 was fixed by the artemis 2.6.3-jbossorg-00013 upgrade, does it follow that this is fixed?
> Regression in SOAP over JMS when WF13 and WF14 are communicating
> ----------------------------------------------------------------
>
> Key: WFLY-11142
> URL: https://issues.jboss.org/browse/WFLY-11142
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Web Services
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Jeff Mesnil
> Priority: Major
>
> There is a regression visible in JBossWS testsuite in SOAP over JMS test when client side and server side are WF13 and WF14 or vice-versa, in other words it is affecting backward and forward compatibility.
> The cause was identified as Artemis upgrade from 1.5.5 to 2.6.3, there is ongoing investigation for gathering more details.
> Exception in case of new client and old server:
> {code:java}
> Exception while processing jms message in cxf. Rolling back: javax.jms.JMSRuntimeException: Invalid address queue://jms.queue.testQueue
> at org.apache.activemq.artemis.jms.client.ActiveMQDestination.fromAddress(ActiveMQDestination.java:119) [artemis-jms-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jms.client.ActiveMQMessage.getJMSReplyTo(ActiveMQMessage.java:356) [artemis-jms-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.cxf.transport.jms.JMSMessageHeadersType.getDestName(JMSMessageHeadersType.java:363) [cxf-rt-transports-jms-3.2.4-jbossorg-1.jar:3.2.4.jbossorg-1]
> at org.apache.cxf.transport.jms.JMSMessageHeadersType.read(JMSMessageHeadersType.java:358) [cxf-rt-transports-jms-3.2.4-jbossorg-1.jar:3.2.4.jbossorg-1]
> at org.apache.cxf.transport.jms.JMSMessageHeadersType.from(JMSMessageHeadersType.java:335) [cxf-rt-transports-jms-3.2.4-jbossorg-1.jar:3.2.4.jbossorg-1]
> at org.apache.cxf.transport.jms.JMSMessageUtils.asCXFMessage(JMSMessageUtils.java:64) [cxf-rt-transports-jms-3.2.4-jbossorg-1.jar:3.2.4.jbossorg-1]
> at org.apache.cxf.transport.jms.JMSDestination.onMessage(JMSDestination.java:237) [cxf-rt-transports-jms-3.2.4-jbossorg-1.jar:3.2.4.jbossorg-1]
> at org.apache.cxf.transport.jms.util.PollingMessageListenerContainer$Poller.run(PollingMessageListenerContainer.java:84) [cxf-rt-transports-jms-3.2.4-jbossorg-1.jar:3.2.4.jbossorg-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_181]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11143) Message sent to JMSReplyTo from old client does not find correct binding
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11143?page=com.atlassian.jira.plugin... ]
Kabir Khan resolved WFLY-11143.
-------------------------------
Resolution: Done
> Message sent to JMSReplyTo from old client does not find correct binding
> ------------------------------------------------------------------------
>
> Key: WFLY-11143
> URL: https://issues.jboss.org/browse/WFLY-11143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Fix For: 15.0.0.CR1
>
>
> There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost.
> Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14.
> Test Scenario:
> * Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue
> * Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14
> * Deploy MDB to server
> ** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue)
> * Receive message from OutQueue
> Result:
> No message is received from OutQueue. There is debug message in server log:
> {code}
> 11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m
> essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie
> s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it
> didn't have a binding on address:jms.queue.OutQueue
> {code}
> which indicates that jms.queue.OutQueue address does not have a binding.
> The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11360) JCAOrderedLastSynchronizationList shouldn't be skipped for org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry registered Synchronizations
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11360?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11360:
----------------------------------------
[~smarlow] what I know the Byteman tests have not been accepted directly to the WildFly testsuite. But it's already some time I was trying similar. But I think the main reason was I needed to process failures with use of Byteman. Maybe [~brian.stansberry] would say more.
I think using Byteman would be the easiest way but by my PoV it's a question if it's a good fit for the integration tests.
> JCAOrderedLastSynchronizationList shouldn't be skipped for org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry registered Synchronizations
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11360
> URL: https://issues.jboss.org/browse/WFLY-11360
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.0.Beta1
> Reporter: Scott Marlow
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 15.0.0.CR1
>
>
> JPA container synchronizations are not registered via JCAOrderedLastSynchronizationList, which means that JCA Synchronization#afterCompletion will not always run after JPA Synchronization#afterCompletion.
> Apparently we are doing a JNDI lookup of "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM integration, which means we are using the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper for Hibernate ORM. Should we also be using the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper class in other WildFly call sites, instead of org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry?
> Call stack below shows the JPA container sync not being registered via JCAOrderedLastSynchronizationList:
> {code}
> 10:48:42,859 ERROR [stderr] (pool-7-thread-7) at java.lang.Thread.dumpStack(Thread.java:1336)
> 10:48:42,865 ERROR [stderr] (pool-7-thread-7) at org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry.registerInterposedSynchronization(ContextTransactionSynchronizationRegistry.java:77)
> 10:48:42,866 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.transaction.TransactionUtil.registerSynchronization(TransactionUtil.java:74)
> 10:48:42,866 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getOrCreateTransactionScopedEntityManager(TransactionScopedEntityManager.java:162)
> 10:48:42,867 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:87)
> 10:48:42,867 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> 10:48:42,867 ERROR [stderr] (pool-7-thread-7) at org.jboss.as.test.integration.jpa.transaction.UnsynchronizedSFSB.createAndPropagatedFindMixExceptionExcepted(UnsynchronizedSFSB.java:88)
> {code}
> Call stack below shows the JCA synchronization is also *NOT* registered correctly via JCAOrderedLastSynchronizationList:
> {code}
> 10:45:06,979 ERROR [stderr] (pool-7-thread-8) java.lang.Exception: Stack trace
> 10:45:06,980 ERROR [stderr] (pool-7-thread-8) at java.lang.Thread.dumpStack(Thread.java:1336)
> 10:45:06,980 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.<init>(SynchronizationImple.java:57)
> 10:45:06,980 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.provider.jboss.JBossJTALocalTransactionProvider.registerInterposedSynchronization(JBossJTALocalTransactionProvider.java:87)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.LocalTransaction.registerInterposedSynchronization(LocalTransaction.java:202)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry.registerInterposedSynchronization(ContextTransactionSynchronizationRegistry.java:77)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.lock(TransactionSynchronizer.java:309)
> 10:45:06,981 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:311)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:564)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:970)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:792)
> 10:45:06,982 ERROR [stderr] (pool-7-thread-8) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35)
> 10:45:06,983 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:106)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:136)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:47)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$1.doPrepare(StatementPreparerImpl.java:87)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:172)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareStatement(StatementPreparerImpl.java:78)
> 10:45:06,984 ERROR [stderr] (pool-7-thread-8) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3152)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3686)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
> 10:45:06,985 ERROR [stderr] (pool-7-thread-8) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
> 10:45:06,986 ERROR [stderr] (pool-7-thread-8) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113)
> 10:45:06,987 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> 10:45:06,988 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77)
> 10:45:06,989 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.wildfly.transaction.client.LocalUserTransaction.commit(LocalUserTransaction.java:53)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.test.integration.jpa.transaction.SFSB1.createEmployee(SFSB1.java:96)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at java.lang.reflect.Method.invoke(Method.java:498)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 10:45:06,990 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 10:45:06,991 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.tx.StatefulBMTInterceptor.handleInvocation(StatefulBMTInterceptor.java:94)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 10:45:06,992 ERROR [stderr] (pool-7-thread-8) at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:137)
> {code}
> Lastly, the following call stack shows the Hibernate ORM sync being correctly registered via JCAOrderedLastSynchronizationList:
> {code}
> 10:52:20,820 ERROR [stderr] (pool-7-thread-1) java.lang.Exception: Stack trace
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at java.lang.Thread.dumpStack(Thread.java:1336)
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.registerInterposedSynchronization(JCAOrderedLastSynchronizationList.java:64)
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.registerInterposedSynchronization(TransactionSynchronizationRegistryWrapper.java:76)
> 10:52:20,821 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.hibernate5.service.WildFlyCustomJtaPlatform$1.registerSynchronization(WildFlyCustomJtaPlatform.java:45)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform.registerSynchronization(AbstractJtaPlatform.java:126)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.joinJtaTransaction(JtaTransactionCoordinatorImpl.java:170)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.pulse(JtaTransactionCoordinatorImpl.java:158)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.<init>(JtaTransactionCoordinatorImpl.java:94)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl.buildTransactionCoordinator(JtaTransactionCoordinatorBuilderImpl.java:29)
> 10:52:20,822 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.AbstractSharedSessionContract.<init>(AbstractSharedSessionContract.java:204)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.AbstractSessionImpl.<init>(AbstractSessionImpl.java:29)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionImpl.<init>(SessionImpl.java:254)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl.openSession(SessionFactoryImpl.java:1290)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl.buildEntityManager(SessionFactoryImpl.java:628)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl.createEntityManager(SessionFactoryImpl.java:614)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.hibernate.internal.SessionFactoryImpl.createEntityManager(SessionFactoryImpl.java:154)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:187)
> 10:52:20,823 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getOrCreateTransactionScopedEntityManager(TransactionScopedEntityManager.java:157)
> 10:52:20,824 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:87)
> 10:52:20,824 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.jpa.container.AbstractEntityManager.joinTransaction(AbstractEntityManager.java:536)
> 10:52:20,824 ERROR [stderr] (pool-7-thread-1) at org.jboss.as.test.integration.jpa.transaction.SFSB1.createEmployee(SFSB1.java:93)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.0.0.Final is not announcing backup when restarted
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Srinivas ev commented on WFLY-11374:
------------------------------------
Hi Jason , Can you take a look on this.
> Master Artemis in Wildfly 10.0.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Reporter: Srinivas ev
> Assignee: Jason Greene
> Priority: Critical
> Attachments: master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master.xml, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months