[jira] Commented: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest

["Oleg Zhurakousky (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40363 ] 

Oleg Zhurakousky commented on SM-628:
-------------------------------------

I agree and that was my initial thought to include the timeout logic as part of MessageList or reuse the existing method. The issue that I see is that MessageList represents one receiver. Most of these instabilities were occurring during a cluster test which means we were dealing with more then one receiver and when more then once receiver is active I observed that messages are equally spread between them (i.e., 10 messages, 2 receivers, each receives 5.) which means I can't even use MessageList logic since in the cluster world the amount of messages received by one receiver is not always equal to the amount of messages sent. 
Even if I assume that such load balancing (2 receivers 5 each) is true round robin and I could potentially reuse MessageList logic (receiver.getMessageList().assertMessagesReceived(NUM_MESSAGES);) by dividing the amount of messages sent by the amount received and place it in NUM_MESSAGES value when I di this check, I have to make sure that in my tests I always have the amount of messages sent divisible my the amount of receivers without a remainder, otherwise if I send 9 messages one receiver gets 5 while other gets 4. Which one ??? I would not know. 
So, the method I proposed in my patch is to have and independent process that sums the amount of messages form all receivers by actually using MessageList.getMessageCount(). 

As to your other question about Resolve. I do not have a huge ego nor do I have any problems with it plus I am just starting my contribution with SM, so I would not mind some one watching a bit over what I do for a while (first time I crashed and burned. . .remember). So I would still like to use Resolve as the way of suggesting a FIX and acceptance of such FIX by peers would grant the Close of issue. We actually use this process internaly in my company 


> org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
> --------------------------------------------------
>
>                 Key: SM-628
>                 URL: https://issues.apache.org/activemq/browse/SM-628
>             Project: ServiceMix
>          Issue Type: Sub-task
>          Components: servicemix-core
>    Affects Versions: 3.0
>            Reporter: Fritz Oconer
>             Fix For: 3.2
>
>         Attachments: SMTestCasesPatches.zip
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.