Hi Hasitha, Very good list, see my comments below.
On Fri, Jun 7, 2013 at 1:11 PM, Malinga Purnasiri <[email protected]> wrote: > Read my comments below. > > > On Fri, Jun 7, 2013 at 12:57 PM, Hasitha Hiranya <[email protected]>wrote: > >> Hi, >> >> As we are planning for the $Subject after we have released MB 2.1.0 >> properly, I want to bring out some changes I would like to see in Message >> Broker architecture and modularization. >> >> >> - Rather than implementing AMQP 1.0.0 ourselves I would like to >> borrow it from outside and integrate. We need to do a comprehensive >> investigation on this and only if there is no suitable solution we should >> carefully plan to implement it ourselves. This will definitely need a >> considerable effort. >> >> Regarding the AMQP1.0 Implementation : We can review > http://activemq.apache.org/apollo/ which supports AMQP 1.0 spec. > Unfortunately they don't have client lib for that so we may have to use > Qpid proton http://qpid.apache.org/proton/ for that purpose. > > We should separate out the in-memory implementation apart from the > Cassandra Message Store implementation. i noted Qpid already has an > in-memory implementation. Maybe we should try to implement it in our way. > >> >> - We should have a very clear interface Message Store. We need to >> promote the interface everywhere in the code. For now we have Cassandra >> Message Store and we access it everywhere in a singleton way, which is not >> going to work. Ideally, we should bring the model to a stage that we can >> plug-in any Message Store implementation and refer it by qpid-config file. >> >> <messageStore> >> >> >> <class>org.wso2.carbon.andes.authentication.andes.CassandraMessageStore</class> >> <MessageStore> >> >> >> - Currently, we have implemented our own way to get messages >> addressed to queues and deliver it to the subscribers and handle >> acknowledgements, neglecting the qpid implementation and their state >> model. >> But still, we do not have our own way of delivering messages to topic >> subscribers. IMO, we need to implement this. Further there is a >> consideration when we are implementing this such that, there should be a >> common place to, >> - track messages >> - track delivery and publishing speed >> - plug message expiration >> - plug message selectors >> - put in delivery headers >> - plug in message priority implementation >> - etc, etc features we provide >> >> Otherwise, we have to maintain two codes when providing every >> single feature. >> > > ++1, for this. > +1, this is more or less refactoring and putting right interfaces. We can start by doing a hackathon to get this done. > >> - Need to fix JMS Transactions properly. IMO it works, but we are >> missing some method implementation regarding transactions in message >> store. >> We need to have a look at Qpid code, understand what they are and >> implement >> them in a suitable way.Even if we are having some singleton classes which >> can be accessed anywhere in code, we should not access them everywhere in >> code. What I mean by that is we need to keep crystal clear separation of >> concerns in class level. >> >> >> - We have given unnecessary overhead to Cassandra Message store. For >> instance, we have started Cluster Manager in Cassandra Message Store which >> is wrong. Message Store class should be only for getting, storing and >> removing messages. It is not suitable to call Andes related operations >> within message store. >> - We must get our security model correct. This should be >> given precedence. >> - We are planning to move to CQL instead of Hector. >> - We are planning to integrate Hazelcast to implement in-memory mode >> in a distributed way. >> >> +1, for this. Totally agree with Hazelcast. > +1 > >> - We should decide on in-order-message delivery. It is so slow that >> it is unusable. Maybe we can use Hazelcast itself to do the >> synchronization >> instead of ZooKeeper we are using now. >> >> yes, it is not useable. But not because of Zookeeper, but because we have to deliver messages one after the other. +1 to scrap this. > >> - All the way, we have to think of tenant aspect too. How billing and >> metering is done? how to separate queue and topic usage tenant-wise etc. >> We >> have addressed this with current implementation to a certain extent. But >> when we design for MB 3.0.0 we should be aware of this from the very >> beginning. >> >> On a side note: >> >>If we are writing AMQP 1.0 we will be making a broker from scratch. >> What we write will not be integatable to Qpid. >> > >>Maybe we should reconsider using ActiveMQ as the core rather than Qpid? >> I see when grading brokers Qpid has relatively less grading. >> > Worth looking at Active MQ before we do MB 3.0. > IMHO I think we knows Qpid enough to fix its problems. > I believe only after the above modular and architectural >> and implementation aspect changes are done we are at a state to implement >> new features for Message Broker 3.0.0 (message selectors, priority queues >> etc). >> >> Then only the model is fixed and release by release MB product would be >> much more stable. >> Then only we can implement features in much more consistence and very >> clear way. >> Then only we can give out new features much more easily with less >> unexpected bugs (as we have a consistent implementation) >> Then only we can make a fancy UI on top of the model. >> >> WDYT on above? >> >> @Team >> Please add the agreeing things on this to MB 3.0.0 roadmap. >> >> Thanks. >> >> -- >> *Hasitha Abeykoon* >> Software Engineer; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>* * >> * >> * >> > > > > -- > Malinga Pathmal, > Technical Lead, WSO2, Inc. : http://wso2.com/ > Phone : (+94) 715335898 > -- ============================ Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
