[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-8620:
-----------------------------------
OK thanks.
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: David Lloyd
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-8620:
---------------------------------
Assignee: David Lloyd (was: Amos Feng)
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: David Lloyd
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-8620:
---------------------------------
[~dmlloyd] I'm not working on this issue.
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10155) Missing message JMS bridge with DUPS_OK quality of service
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10155:
----------------------------------
Summary: Missing message JMS bridge with DUPS_OK quality of service
Key: WFLY-10155
URL: https://issues.jboss.org/browse/WFLY-10155
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
There is missing one message in scenario where JMS bridge (with DUPS_OK) resending messages from one server to another. Durint resending target server is killed and bridge does failover to backup.
After failover in server logs there are lots of warns/errors:
{code}
05:39:01,697 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-144) AMQ342009: JMS Bridge N/A failed to send + acknowledge batch, closing JMS objects: javax.jms.JMSException: Duplicate message detected - me
ssage will not be routed. Message information:LargeServerMessage[messageID=2147485500,durable=true,userID=d8ea8e0a-326b-11e8-b74b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:39:01 EDT 2018,expiration=0, dur
able=true, address=jms.queue.OutQueue,size=410263,properties=TypedProperties[__AMQ_CID=bd95a355-326b-11e8-b74b-fa163e64a220,_AMQ_ROUTING_TYPE=1,AMQ_BRIDGE_MSG_ID_LIST=ID:c13a41dc-326b-11e8-949b-fa163e64a220,JMSX
DeliveryCount=10,count=989,color=RED,counter=990,_AMQ_DUPL_ID=fde672e0-e858-4c50-a148-a0b7a4a223591522229901951,_AMQ_LARGE_SIZE=409615]]@1304406481
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:423) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:319) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.simpleCommit(ActiveMQSessionContext.java:381) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:862) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:835) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.client.ActiveMQSession.commit(ActiveMQSession.java:231) [artemis-jms-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.sendBatchNonTransacted(JMSBridgeImpl.java:1338) [artemis-jms-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.sendBatch(JMSBridgeImpl.java:1298) [artemis-jms-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$1700(JMSBridgeImpl.java:74) [artemis-jms-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$SourceReceiver.run(JMSBridgeImpl.java:1694) [artemis-jms-server-2.5.0.jar:2.5.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_162]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_162]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_162]
Caused by: ActiveMQDuplicateIdException[errorType=DUPLICATE_ID_REJECTED message=Duplicate message detected - message will not be routed. Message information:LargeServerMessage[messageID=2147485500,durable=true,u
serID=d8ea8e0a-326b-11e8-b74b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:39:01 EDT 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=410263,properties=TypedProperties[__AMQ_CID=bd95a355-326b
-11e8-b74b-fa163e64a220,_AMQ_ROUTING_TYPE=1,AMQ_BRIDGE_MSG_ID_LIST=ID:c13a41dc-326b-11e8-949b-fa163e64a220,JMSXDeliveryCount=10,count=989,color=RED,counter=990,_AMQ_DUPL_ID=fde672e0-e858-4c50-a148-a0b7a4a2235915
22229901951,_AMQ_LARGE_SIZE=409615]]@1304406481]
... 13 more
05:39:01,699 WARN [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@2076a02)) AMQ222149: Message Reference[3056]:RELIABLE:Co
reMessage[messageID=3056,durable=true,userID=c1347573-326b-11e8-949b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:38:21 EDT 2018,expiration=0, durable=true, address=jms.queue.InQueue,size=10673,properties=Ty
pedProperties[__AMQ_CID=be528a5c-326b-11e8-949b-fa163e64a220,_AMQ_ROUTING_TYPE=1,count=980,counter=981,_AMQ_DUPL_ID=13adf1ec-581f-42e4-835b-0e6e33a4e1191522229901913,color=GREEN]]@511432790 has reached maximum d
elivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.InQueue
05:39:01,700 WARN [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@2076a02)) AMQ222149: Message Reference[3058]:RELIABLE:CoreMessage[messageID=3058,durable=true,userID=c1349c84-326b-11e8-949b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:38:21 EDT 2018,expiration=0, durable=true, address=jms.queue.InQueue,size=20914,properties=TypedProperties[__AMQ_CID=be528a5c-326b-11e8-949b-fa163e64a220,_AMQ_ROUTING_TYPE=1,count=981,counter=982,_AMQ_DUPL_ID=6feb66cd-8616-4dff-8775-3f85a4b9bdbb1522229901914,color=RED]]@1150646585 has reached maximum delivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.InQueue
....
05:39:01,706 WARN [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@2076a02)) AMQ222149: Message Reference[3082]:RELIABLE:CoreMessage[messageID=3082,durable=true,userID=c13d4f1d-326b-11e8-949b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:38:21 EDT 2018,expiration=0, durable=true, address=jms.queue.InQueue,size=10673,properties=TypedProperties[__AMQ_CID=be528a5c-326b-11e8-949b-fa163e64a220,_AMQ_ROUTING_TYPE=1,count=990,counter=991,_AMQ_DUPL_ID=f802f4b7-e0a1-4dee-acc7-0b11963bec401522229901971,color=GREEN]]@2708478 has reached maximum delivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.InQueue
{code}
So the missing message ended up in DLQ as it could not be delivered to target queue. It looks like that _AMQ_DUPL_ID might trigger dup message detection in target queueu however such message did not get there.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10154) Lost message when MDB is resending messages under high load
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10154:
----------------------------------
Summary: Lost message when MDB is resending messages under high load
Key: WFLY-10154
URL: https://issues.jboss.org/browse/WFLY-10154
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Miroslav Novak
Assignee: Martyn Taylor
Priority: Blocker
Test scenario:
* Start cluster A of nodes node-1, node-3
* Start cluster B of nodes node-2, node-4
* Send messages to queue on node-1
* Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database
* Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database
* Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages
* Restart failed server
* Let MDBs to process remaining messages
Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in
Actual Result:
Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2.
This looks like broker related regression against Artemis 1.5.
Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
Artemis tag 2.5.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-9530) Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9530?page=com.atlassian.jira.plugin.... ]
tommaso borgato updated WFLY-9530:
----------------------------------
Attachment: sample-app.zip
> Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9530
> URL: https://issues.jboss.org/browse/WFLY-9530
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 12.0.0.Beta1, 12.0.0.Final
>
> Attachments: sample-app.war, sample-app.zip
>
>
> When deploying a legacy (non-JPA) Hibernate application with level 2 cache enabled, the following WARN is logged:
> {code}
> ... WARN [org.hibernate.cache.infinispan.impl.BaseRegion] ... Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-9530) Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9530?page=com.atlassian.jira.plugin.... ]
tommaso borgato updated WFLY-9530:
----------------------------------
Attachment: sample-app.war
> Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9530
> URL: https://issues.jboss.org/browse/WFLY-9530
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 12.0.0.Beta1, 12.0.0.Final
>
> Attachments: sample-app.war, sample-app.zip
>
>
> When deploying a legacy (non-JPA) Hibernate application with level 2 cache enabled, the following WARN is logged:
> {code}
> ... WARN [org.hibernate.cache.infinispan.impl.BaseRegion] ... Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10078) [Artemis 2.x Upgrade] Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10078?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10078:
-------------------------------
Affects Version/s: (was: 13.0.0.Beta1)
> [Artemis 2.x Upgrade] Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10078
> URL: https://issues.jboss.org/browse/WFLY-10078
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: server1-trace.log, server1.log, server2-trace.log, server2.log
>
>
> Across all replicated HA tests I often see an issue that initial synchronization between Live and Backup was not triggered.
> *Scenario*
> # There are two Wildfly servers configured as replicated Live-Backup pair.
> # Live server is killed/shutdown
> *Expectation:* Backup server becomes active.
> *Reality:* Backup server does not become active, because initial synchronization with Live server was not triggered.
> *Users impact:* Replicated HA feature doesn't work properly.
> *Blocker* priority was set because this is regression against previous Wildfly releases.
> *Detail description of the issue*
> In the trace log there is last message from the {{SharedNothingBackupActivation}} which says that it is waiting on cluster connection. It is interested that JGroups subsystem is booting after this message was logged. However I am not sure if this could cause the issue.
> {code}
> 13:42:06,489 DEBUG [org.apache.activemq.artemis.core.client.impl.Topology] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Topology@6a834ff0[owner=ServerLocatorImpl [initialConnectors=[],
> discoveryGroupConfiguration=DiscoveryGroupConfiguration{name='dg-group1', refreshTimeout=10000, discoveryInitialWaitTimeout=10000}]] is sending topology to org.apache.activemq.artemis.core.server.impl.NamedLiveN
> odeLocatorForReplication@38150570
> 13:42:06,489 TRACE [org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Waiting on cluster connection
> 13:42:06,502 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel ejb
> 13:42:06,503 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel ejb
> 13:42:06,504 INFO [org.infinispan.CLUSTER] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,506 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
> 13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,510 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb
> 13:42:06,510 INFO [org.infinispan.CLUSTER] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,516 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,529 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,551 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-7) ISPN000128: Infinispan version: Infinispan 'Gaina' 9.2.0.Final
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years