[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)
7 years, 10 months
[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)
7 years, 10 months
[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)
7 years, 10 months
[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)
7 years, 10 months
[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)
7 years, 10 months
[JBoss JIRA] (WFLY-10153) Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10153:
----------------------------------
Summary: Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
Key: WFLY-10153
URL: https://issues.jboss.org/browse/WFLY-10153
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Beta1
Reporter: Erich Duda
Assignee: Jeff Mesnil
Priority: Blocker
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)
7 years, 10 months
[JBoss JIRA] (WFLY-10152) Last value queues do not work
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10152:
----------------------------------
Summary: Last value queues do not work
Key: WFLY-10152
URL: https://issues.jboss.org/browse/WFLY-10152
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Martin Styk
Assignee: Martyn Taylor
Priority: Blocker
Last value queues are not working as expected.
# Set {{last-value-queue="true"}} for an address settings {{#}}
# Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
# Receiver receives 10 messages. (it is expected to receive the single message)
This looks like broker related regression against Artemis 1.5.
Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support IMPORT decisions between DMN files
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1663?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1663:
-----------------------------------
Attachment: dmn import defaults.odt
> Kie DMN doesn't support IMPORT decisions between DMN files
> ----------------------------------------------------------
>
> Key: DROOLS-1663
> URL: https://issues.jboss.org/browse/DROOLS-1663
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Stylianos Koussouris
> Assignee: Matteo Mortari
> Attachments: IMG_2197.jpg, IMG_2198.jpg, IMG_2199.jpg, dmn import defaults.odt
>
>
> DMN Spec 1.1
> Page 40.
> import: Import [*] This attribute is used to import externally defined elements and
> make them available for use by elements in this Definitions.
> Section 6.3.3 Import metamodel
> The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months