Forwarding to Architecture@
On Mon, Mar 10, 2014 at 9:07 AM, Iranga <[email protected]> wrote: > > > Hi Hasitha, > > can we add test cases for message send/receive through > > secured channel(ssl) > fail over ( cluster specific) > Different message content size > Integrated scenario receiving and subscribing from topics and queues. > > Regards, > Iranga > > > > On 2014 මාර්තු 10, at පෙ.ව. 8.07, Shevan Goonetilleke <[email protected]> > wrote: > > Good work on the test suite Hasitha, it was badly needed for MB! > > And yes, please forward this to Architecture, not support-dev. > > > > On Sun, Mar 9, 2014 at 6:33 PM, Chanaka Fernando <[email protected]>wrote: > >> Hi Hasitha, >> >> Shouldn't this mail need to go in engineering-group(or >> architecture-group), rather than support-dev group? >> >> >> Thanks, >> Chanaka >> >> >> On Sun, Mar 9, 2014 at 4:53 PM, Hasitha Hiranya <[email protected]>wrote: >> >>> Hi, >>> >>> Please mention if there is any other combination of send/receive >>> sequence worth tested with WSO2 Message Broker. >>> We will add it to the integration tests. >>> >>> @Krishantha, >>> >>> I suppose we can easily extend the same to write cluster wide tests >>> easily. >>> Please share your thought. >>> >>> @Deep, >>> >>> What about the progress of puppet scripts for deploying MB ? If so, we >>> can get hold of Kishantha and discuss how these bit can be bought to the >>> Automation Test Framework. >>> >>> Thanks. >>> >>> >>> On Sun, Mar 9, 2014 at 4:46 PM, Hasitha Hiranya <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> Following are the other test cases added >>>> >>>> JMS Subscriber Transactions - >>>> >>>> 1. JMSSubscriberTransactionsSessionCommitRollbackTestCase - >>>> >>>> /** >>>> * 1. start a queue receiver with trasacted sessions >>>> * 2. send 10 messages >>>> * 3. after 10 messages are received rollback session >>>> * 4. do same 5 times.After 50 messages received commit the session and >>>> close subscriber >>>> * 5. analyse and see if each message is duplicated five times >>>> * 6. do another subscription to verify no more messages are received >>>> */ >>>> >>>> Eventing related test cases - >>>> >>>> EventTestCase - specify a event sink url and send a message and see if >>>> it is consumed properly. >>>> >>>> Thanks. >>>> >>>> >>>> On Sun, Mar 9, 2014 at 4:42 PM, Hasitha Hiranya <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> Following are the AMQP based test cases implemented for "*TOPICS*" >>>>> and "*DURABLE TOPICS*". >>>>> >>>>> 1. SingleTopicPublishSubscribeTestCase >>>>> >>>>> /** >>>>> * subscribe to a topic and send 1000 messages and verify if messages >>>>> are being received >>>>> */ >>>>> >>>>> 2. TopicMessageSequencialAndDuplicateTestCase >>>>> >>>>> /** >>>>> * 1. Send messages to a single topic and receive them >>>>> * 2. listen for some more time to see if there are duplicates coming >>>>> * 3. check if messages were received in order >>>>> * 4. check if messages have any duplicates >>>>> */ >>>>> >>>>> 3. MultipleTopicPublishSubscribeTestCase >>>>> >>>>> /** >>>>> * 1. use two topics t1, t2. 2 subscribers for t1 and one subscriber >>>>> for t2 >>>>> * 2. use two publishers for t1 and one for t2 >>>>> * 3. check if messages were received correctly >>>>> */ >>>>> >>>>> 4. HierarchicalTopicsTestCase >>>>> >>>>> >> topicOnlyCase >>>>> >>>>> /** >>>>> * topic only option. Here we subscribe to games.cricket and >>>>> verify that only messages >>>>> * specifically published to games.cricket is received >>>>> */ >>>>> >>>>> >> ImmediateChildrenCase >>>>> >>>>> /** >>>>> * immediate children option. Here you subscribe to the first >>>>> level of sub-topics but not to the topic itself. >>>>> * 1. subscribe to games.* and publish to games. Should receive no >>>>> message >>>>> * 2. subscribe to games.* and publish to games.football. Messages >>>>> should be received >>>>> */ >>>>> >>>>> >> TopicAndChildrenCase >>>>> >>>>> /** >>>>> * topic and children option. Here messages published to topic >>>>> itself and any level >>>>> * in the hierarchy should be received >>>>> */ >>>>> >>>>> 5. DurableTopicTestCase >>>>> >>>>> /** >>>>> * 1. start a durable topic subscription >>>>> * 2. send 1500 messages >>>>> * 3. after 500 messages were received close the subscriber >>>>> * 4. subscribe again. after 500 messages were received unsubscribe >>>>> * 5. subscribe again. Verify no more messages are coming >>>>> */ >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> On Sun, Mar 9, 2014 at 4:36 PM, Hasitha Hiranya <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Following are the AMQP based test cases implemented for "*QUEUES*". >>>>>> >>>>>> 1. SingleQueueSendReceiveTestCase >>>>>> >>>>>> /** >>>>>> * Send messages to a single queue and consume them and see if sent >>>>>> messages are received >>>>>> */ >>>>>> >>>>>> 2. QueueMessageSequencialAndDuplicateTestCase >>>>>> >>>>>> /** >>>>>> * 1. send 1000 messages and subscribe them for a single queue (set >>>>>> expected count to more than 1000 so it will wait) >>>>>> * 2. check if messages were received in order >>>>>> * 3. check if there are any duplicates >>>>>> */ >>>>>> >>>>>> 3. QueueSubscriptionsBreakAndReceiveTestCase >>>>>> >>>>>> /** >>>>>> * 1. subscribe to a single queue which will take 1/5 messages of >>>>>> sent and stop >>>>>> * 2. send messages to the queue >>>>>> * 3. close and resubscribe 5 times to the queue >>>>>> * 4. verify message count is equal to the sent total >>>>>> */ >>>>>> >>>>>> 4. MultipleQueueSendReceiveTestCase >>>>>> >>>>>> /** >>>>>> * 1. use two queues q1, q2. 2 subscribers for q1 and one subscriber >>>>>> for q2 >>>>>> * 2. use two publishers for q1 and one for q2 >>>>>> * 3. check if messages were received correctly >>>>>> */ >>>>>> >>>>>> 5. ClientAcknowledgementsTestCase >>>>>> >>>>>> /** >>>>>> * 1. start a queue receiver in client ack mode >>>>>> * 2. receive messages acking message bunch to bunch >>>>>> * 3. after all messages are received subscribe again and verify n >>>>>> more messages come >>>>>> */ >>>>>> >>>>>> 6. QueueMessageRedeliveryWithAckTimeOutTestCase >>>>>> >>>>>> /** >>>>>> * 1. subscribe to a single queue using Client Ack >>>>>> * 2. this subscriber will wait a long time for messages >>>>>> (defaultAckWaitTimeout*defaultMaxRedeliveryAttempts) >>>>>> * 3. subscriber will never ack for messages >>>>>> * 4. subscriber will receive same message until >>>>>> defaultMaxRedeliveryAttempts breached >>>>>> * 5. after that message will be written to dlc >>>>>> * 6. no more message should be delivered after written to DLC >>>>>> */ >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> On Sun, Mar 9, 2014 at 4:33 PM, Hasitha Hiranya <[email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> In previous versions of message broker releases, we had a limited >>>>>>> number of integration tests. It was a major pain when testing WSO2 >>>>>>> Message >>>>>>> Broker as whenever we do a change, we wanted to test the somewhat >>>>>>> complex >>>>>>> message send/receive sequences manually over and over again. >>>>>>> >>>>>>> For the yet to be released MB version, I have implemented a test >>>>>>> suite covering almost all the basic cases (limited to single node MB). >>>>>>> Following is the test case hierarchy I introduced considering MQTT Based >>>>>>> test that are yet to come. >>>>>>> >>>>>>> <Selection_010.png> >>>>>>> >>>>>>> >>>>>>> I will post the details after finalizing the tests. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> -- >>>>>>> *Hasitha Abeykoon* >>>>>>> Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>> *cell:* *+94 719363063* >>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Hasitha Abeykoon* >>>>>> Software Engineer; WSO2, Inc.; http://wso2.com >>>>>> *cell:* *+94 719363063* >>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Hasitha Abeykoon* >>>>> Software Engineer; WSO2, Inc.; http://wso2.com >>>>> *cell:* *+94 719363063* >>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Hasitha Abeykoon* >>>> Software Engineer; WSO2, Inc.; http://wso2.com >>>> *cell:* *+94 719363063* >>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>> >>>> >>> >>> >>> -- >>> *Hasitha Abeykoon* >>> Software Engineer; WSO2, Inc.; http://wso2.com >>> *cell:* *+94 719363063* >>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>> >>> >> >> >> -- >> -- >> Chanaka Fernando >> Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 773337238 >> Blog : http://soatutorials.blogspot.com >> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >> Twitter:https://twitter.com/chanakaudaya >> Wordpress:http://chanakaudaya.wordpress.com >> >> >> >> > > > -- > Shevan Goonetilleke > Director of Engineering > WSO2, Inc. > lean.enterprise.middleware > m: +94777340680 > w: http://wso2.com > > -- *Hasitha Abeykoon* Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
