I got the durable topic scenario working (I am testing with GQ/NQ included as Sajini's fixes are on the way) So, I am testing subscription perspective only.
Did following tests. create with sub id= x topic=y. disconnect and try to connect again - passed create with sub id= x topic=y. kill subscription and try to connect again - passed create with sub id= x topic=y. try another subscription with same params. rejects the subscription - passed create with sub id= x topic=y. try another with sub id=z topic=y. Allowed - passed above mutiple subscribers killed - passed create with sub id= x topic=y. Kill it. Then try with sub id= x topic=z. rejects the subscription - passed create with sub id= x topic=y. Kill it. INSTANTLY create same subscription again. Subscription rejected - failed (*do we need to address this?*) above create subscription again - passed create with sub id= x topic=y. Create a normal topc subscription topic=y - passed kill above individually - passed create with sub id= x topic=y. Unsubscribe. Now try sub id= x topic=y - failed create with sub id= x topic=y. Unsubscribe. Now try sub id= z topic=y - failed create with sub id= x topic=y. Unsubscribe. Now try sub id= x topic=z - failed Last three failed as qpid did not said to remove bindings and delete queue. Maybe an issue with my client. Will check more. On Sat, Sep 27, 2014 at 5:50 PM, Hasitha Hiranya <[email protected]> wrote: > This change working fine in standalone mode now. According to above logic, > if Hazlecast side works there is no reason for MB not to work fine in > cluster mode. > > TODO: > > 1. Check this in cluster mode > 2. Carefully think about durable topic subscriptions > 3. handle the case where MB shut down when there are live subscriptions > 4. handle case where MB killed when there are live subscribers > > On Sat, Sep 27, 2014 at 5:50 PM, Hasitha Hiranya <[email protected]> > wrote: > >> I have verified that AndesRecovery handler is working correctly. >> After getting it verified I have "short-circuited" cluster changes to be >> triggered inside local changes. >> So we do not need to write codes specifically for standalone mode. >> >> On Sat, Sep 27, 2014 at 5:49 PM, Hasitha Hiranya <[email protected]> >> wrote: >> >>> Facts >>> We deal with Qpid only thro 2 classes >>> >>QpidAndesBridge - qpid tells to kernel >>> >>VirtualHostConfigSynchronizer - kernel tells to qpid >>> >>> Concerns >>> Have we not still got rid of CassandraMessageStore class completely?? >>> >>> On Sat, Sep 27, 2014 at 5:49 PM, Hasitha Hiranya <[email protected]> >>> wrote: >>> >>>> Now we have a concept called subscription disconnect. This >>>> specifically come into play during durable topic subscriptions - need to >>>> think more >>>> >>>> In all other occasions we just delete the subscription. No disconnect. >>>> >>>> On Sat, Sep 27, 2014 at 5:49 PM, Hasitha Hiranya <[email protected]> >>>> wrote: >>>> >>>>> 1. When storing a queue/binding/exchange in DB >>>>> 2. and when notifying the change is sent via Hazlecast >>>>> >>>>> same encoded string is used. So now the recovery from DB is >>>>> straightforward. >>>>> >>>>> On Sat, Sep 27, 2014 at 5:48 PM, Hasitha Hiranya <[email protected]> >>>>> wrote: >>>>> >>>>>> Removed following classes >>>>>> >>>>>> interface ClusterCoordinationManager >>>>>> class ClusterwideSubscriptionChangeNotifier >>>>>> SubscriptionNotification - now all queues/exchanges/bindings are >>>>>> synced by a common notification type called "clusterSubscription" >>>>>> >>>>>> ClusterSubscription structure - >>>>>> >> notification message description >>>>>> >> notification body as a encoded string >>>>>> >> notification type - add/delete etc >>>>>> >>>>>> On Sat, Sep 27, 2014 at 5:48 PM, Hasitha Hiranya <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Moved initalizing code of andes kernel to a new class >>>>>>> >>>>>>> AndesKernelBoot - now Andes kernel startup code lies here. Decoupled >>>>>>> from Qpid >>>>>>> >>>>>>> >>loadConfigurations - done from outside >>>>>>> >>startAndesStores - done from outside >>>>>>> >>startAndesComponents() >>>>>>> >>startHouseKeepingThreads() >>>>>>> >>syncNodeWithClusterState() >>>>>>> >>registerMBeans() >>>>>>> >>startMessaging() >>>>>>> >>>>>>> On Sat, Sep 27, 2014 at 5:47 PM, Hasitha Hiranya <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Introduced following new classes >>>>>>>> >>>>>>>> ClusterCoordinationHandler implements QueueListener, >>>>>>>> ExchangeListener, BindingListener, SubscriptionListener >>>>>>>> >>>>>>>> >> one place to handle all cluster coordination >>>>>>>> >>>>>>>> AndesRecoveryTask - reload from DB time to time in case of cluster >>>>>>>> notification miss and simulate cluster notifications - TODO: to update >>>>>>>> default recovery task interval in config file >>>>>>>> >>>>>>>> AMQPConstructStore - keeps queues/bindings/exchanges - ultimately >>>>>>>> refers AndesContextStore >>>>>>>> >>>>>>>> On Sat, Sep 27, 2014 at 5:46 PM, Hasitha Hiranya <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I began the $subject. >>>>>>>>> Idea is to instead of deriving queues/bindings/exchanges from >>>>>>>>> subscriptions sync them Independently. >>>>>>>>> >>>>>>>>> I introduced QueueListener/BindingListener/ExchangeListner in the >>>>>>>>> same way as subscription listener >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Hasitha Abeykoon* >>>>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>>>> *cell:* *+94 719363063* >>>>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Hasitha Abeykoon* >>>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>>> *cell:* *+94 719363063* >>>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Hasitha Abeykoon* >>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>> *cell:* *+94 719363063* >>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Hasitha Abeykoon* >>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>> *cell:* *+94 719363063* >>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Hasitha Abeykoon* >>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>> *cell:* *+94 719363063* >>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Hasitha Abeykoon* >>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>> *cell:* *+94 719363063* >>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>> >>>> >>> >>> >>> -- >>> *Hasitha Abeykoon* >>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>> *cell:* *+94 719363063* >>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>> >>> >> >> >> -- >> *Hasitha Abeykoon* >> Senior Software Engineer; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >> >> > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
