[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1862) Enhancement - No duplicated messages when cluster is split up into to sub clusters

Miroslav Novak (JIRA) jira-events at lists.jboss.org
Wed Apr 27 11:03:18 EDT 2011


    [ https://issues.jboss.org/browse/JBMESSAGING-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598421#comment-12598421 ] 

Miroslav Novak commented on JBMESSAGING-1862:
---------------------------------------------

Please see jira: JBPAPP-6076

> Enhancement - No duplicated messages when cluster is split up into to sub clusters
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1862
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1862
>             Project: JBoss Messaging
>          Issue Type: Enhancement
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Miroslav Novak
>            Assignee: Miroslav Novak
>
> For now the behaviour is following: 
> Test configuration:
> 4 nodes EAP 4.3.8 in cluster, MySQL 5 for JBM, clustered queue deployed on all nodes.
> Stand alone producer, receiver.
> We use ConnectionFactory in following scenario for standalone producer and consumer (using auto_acknoledge mode) to be sure that client is connected to required node.
> Test scenario:
> 1) Start all nodes, There is now cluster of four nodes A - B - C - D with clustered queue "testDistributedQueue"
> 2) Send 500 messages into each node
> 3) Check status of DB, you should see 500 messages for each node
> 4) Remove network connectivity between nodes A-C, A-D, B-C, B-D (so there are now connected only A-B,C-D)
> 5) Wait (5 min)
> 6) Disconnect all nodes from DB
> 7) Try read from A
> 8) Try read from B 
> 9) Look to database - each node have 500 messages in the queue
> 10) Reconnect all nodes to DB
> 11) Look to database you will see that fail-over occurs. Number of messages on each node - A: 1499 B:499 C:0 D:0 - two messages are lost - it's current behaviour
> 12) Read from A - 1998 messages is received and there are no messages in DB (it's ok)
> 13) Read from B - 0 messages is received (it's ok)
> 14) Read from C - 500 messages is received. Those are duplicated messages and the new regression.
> 15) Read from D - 500 messages is received. Those are duplicated messages and the new regression.
> Also when A is reconnected to DB (step 10) then nodes C and D are removed from jbm_postoffice table. But those nodes still live.
> As enhancement this should be fixed. 
> An expected behaviour should be specified but those things should hold:
> a) No duplicated messages should occur in step 14. and 15.  
> b) No message loss after step 10.
> c) Client should be able to read all the messages from clustered queue on any node.
> Thanks,
> Mirek

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jboss-jira mailing list