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>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
