[jira] Reopened: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened SM-628: FYI, we tend to resolve issue when the patches are actually committed (but maybe we should change that, as we don't make much differences between resolved and closed: how do you usually use these two states ?) Wrt to your patch, the idea is good. However, this job should be handled by the MessageList. For example, when calling: receiver.getMessageList().assertMessagesReceived(NUM_MESSAGES); the assertMessagesReceived calls waitForMessagesToArrive which already waits for the number of message to arrive. if extending the timeout is sufficient, maybe we should just change the default timeout in the MessageList from 4000 ms to much more. Wdyt ? 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.
[jira] Resolved: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved SM-628. - Resolution: Fixed I was able to replicate inconsistencies of this and other similar tests and figure out why they were so unstable. Even though in the async message world we have to do something to give messages enough time to arrive It is hard to rely on Thread.sleep(...). Some of us have better hardware then others, thus making it difficult to know the optimum time needed for messages to arrive. Here is what I did to make sure that I am right Firs I ran this test several times with different Thread.sleep(..) values and start noticing that 9 out of 10 times it will run just fine, but then it would fail the test (mostly in the Cluster portion of the test) failing on this line: assertFalse(receiver.getMessageList().hasReceivedMessage()); That was interesting because we are flushing all the messages before each message batch send. I was even able to verify with few debug statements that receivers are empty. I start suspecting that messages were still arriving after flush was executed. To verify it I had to modify the message content to include some type of unique identifier. When I did (simple static counter such as 1, 2, 3, 4 . . . etc.), everything became clear. First test in the cluster test sends a batch of 10 messages with identifier 1, then flush, then second batch with identifier 2 and so on. Well, very quickly I start seeing that occasionally after sending second batch with identifier 2, I would still get a message on the receiver with identifier 1. So, that is pretty much the story, if you guys need more details, just let me know. The good news is that there are several tests that are very similar (JCAFlowTest, MultimpleJMSFlowTest etc.) which have the same problem and obviously the same fix. I am recommending the attached two patches. One is a new class (ClusterFlowTestHelper) that should be a base class for all the tests similar to JMSFlow test and obviously JMSFlowTest patch which removes all the Thread.sleep(), extends ClusterFlowTestHelper and calls its helper methods to verify that messages were received. Currently I am setting the timeout to 4000 msc even though on my machine all 10 messages arrive in under 200 msc. I've also added another assert, so if after all messages do not arrive in the allotted time, then the test will fail (but at least we'll know exactly why). If you agree with the proposed solution, I'll take care of all other tests in the similar way. 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.
ServiceMix board report - oct 2007
This report for October is the first report since ServiceMix graduation last month. ServiceMix resources have not been moved yet. Hopefully everything will be sorted out soon. We have released our first non incubating version of ServiceMix, the 3.1.2 version, on September 25th. We are currently preparing for our next big release, ServiceMix 3.2, which is planned for the end of October. Work has started on the next major version 4.0 which will be based on OSGi. On the community side, both developer and user community are very active. A new committer has been voted in. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-624) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40368 ] Oleg Zhurakousky commented on SM-624: - Can someone please give me quick pointer on this one. This test only has one test() method which basically follows the flow of 1. Create 4 containers 2. Start 4 Containers 3. Activate Receivers in these containers and so on Then stopping and starting again and producing log messages that look like this: 13:50:33,671 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 0, 0, 0, 0 13:50:33,703 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container0) started 13:50:37,703 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 1, 0, 0, 0 13:50:37,703 | WARN | main | ClientFactory| emix.jbi.framework.ClientFactory 89 | Cound not start ClientFactory: javax.naming.NamingException: Something already bound at ClientFactory 13:50:37,718 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container1) started 13:50:41,718 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 2, 2, 0, 0 13:50:41,718 | WARN | main | ClientFactory| emix.jbi.framework.ClientFactory 89 | Cound not start ClientFactory: javax.naming.NamingException: Something already bound at ClientFactory 13:50:41,734 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container2) started 13:50:45,734 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 3, 3, 3, 0 13:50:45,734 | WARN | main | ClientFactory| emix.jbi.framework.ClientFactory 89 | Cound not start ClientFactory: javax.naming.NamingException: Something already bound at ClientFactory 13:50:45,750 | INFO | main | JBIContainer | cemix.jbi.container.JBIContainer 642 | ServiceMix JBI Container (container3) started 13:50:49,750 | INFO | main | MultipleJMSFlowTest | nmr.flow.jms.MultipleJMSFlowTest 103 | Nodes: 4, 4, 4, 4 There are no assertions, and so far it does not produce any errors What was the thought behind this test? Could it be incomplete? Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest --- Key: SM-624 URL: https://issues.apache.org/activemq/browse/SM-624 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Environment: Windows and linux Reporter: Fritz Oconer Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-1100) Allow containerName to be specified on the command line for projectDeploy
[ https://issues.apache.org/activemq/browse/SM-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Greer updated SM-1100: Attachment: mojo-containerName-patch.txt Allow containerName to be specified on the command line for projectDeploy - Key: SM-1100 URL: https://issues.apache.org/activemq/browse/SM-1100 Project: ServiceMix Issue Type: New Feature Components: tooling Reporter: Brian Greer Priority: Minor Attachments: mojo-containerName-patch.txt The containerName should be specifiable from the command line during deploy, e.g.: mvn jbi:projectDeploy -DcontainerName=mycontainer Patch is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SM-628) org.apache.servicemix.jbi.nmr.flow.jms.JMSFlowTest
[ https://issues.apache.org/activemq/browse/SM-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40363 ] ozhurakousky edited comment on SM-628 at 10/12/07 6:23 AM: --- 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(). NOTE: Just thought about something. I can reuse waitForMessagesToArrive(..) method in my ClusterHelperTest, to eliminate my timeout logic, but I still have to sum all of the messages before I return true or false. 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 was (Author: ozhurakousky): 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.
[jira] Updated: (SM-1100) Allow containerName to be specified on the command line for projectDeploy
[ https://issues.apache.org/activemq/browse/SM-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Greer updated SM-1100: Attachment: (was: mojo-containerName-patch.txt) Allow containerName to be specified on the command line for projectDeploy - Key: SM-1100 URL: https://issues.apache.org/activemq/browse/SM-1100 Project: ServiceMix Issue Type: New Feature Components: tooling Reporter: Brian Greer Priority: Minor Attachments: mojo-containerName-patch.txt The containerName should be specifiable from the command line during deploy, e.g.: mvn jbi:projectDeploy -DcontainerName=mycontainer Patch is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
