On Wed, Aug 14, 2013 at 7:58 PM, Isuru Perera <[email protected]> wrote:
> > On Wed, Aug 14, 2013 at 7:02 PM, Nirmal Fernando > <[email protected]>wrote: > >> >> On Aug 14, 2013 4:55 AM, "Isuru Perera" <[email protected]> wrote: >> > >> > Well, if we support other Message Brokers with extension points, there >> is no need to start internal MB with Cassandra data store. >> > >> > I just need to decouple Message Broker from Cloud Controller since it >> brings lot of dependencies. As a result, I cannot proceed with jclouds >> upgrade due to dependency issue with guava libraries. (I mentioned this in >> another thread) >> > >> >> Well, there should be another way to solve the original problem you have, >> instead of chosing the lazy path :-) >> > I agree that removing MB features is just an easy path to solve the > original problem! But you cannot call it lazy, since I also plan to > implement a workaround! :-) > > Besides, the problem is with external features and I'm just trying to > solve it within Stratos code base. > >> > Since you started the discussion on supporting external topology >> publisher, I think it would a good starting point to remove MB features. >> Even running a message broker externally would be okay since this is a PaaS >> and it is just another process in the system. >> > >> >> Topic resides in whatever the message broker is of utmost importance for >> Apache Stratos to function properly. If we remove the default embedded MB, >> what would we ship by default? >> >> Initially we used an external MB, but why we decided to get only >> necessary MB related features was to minimize the # of JVMs and make it >> easily configurable. >> > My point is that we do not need to bundle a Message Broker with Cloud > Controller. We can initially support Apache ActiveMQ and WSO2 MB. We will > provide detailed configuration steps in Cloud Controller for both. There is > nothing to configure in Message Broker. Then users can choose a Message > Broker of their choice without any complexity. Adding an extra JVM process > in to the system is not an issue in my opinion. > Well, if I am new to Apache Stratos and wanna try it out, I surely don't want to do all those manual configurations etc. We should think from the user perspective as well and should not discourage new users IMO. > > If I understand correctly, your extension point is about adding >> another class. That is good if the new MB topology publisher is completely >> different, but we can simply support many more message brokers with a >> single class by providing relevant parameters, such as >> java.naming.factory.initial >> > >> >> Well this is an improvement that one could make. You have the foundation >> built, play wisely. >> > I'm working on the improvement. :) > While you are trying to make a single class to support multiple providers, you're making CC hard to configure. For an example currently to configure topology publisher, you only need following: <topologySync enable="true"> <!-- properties related to topology syncher --> <property name="className" value="org.apache.stratos.cloud.controller.ABC"/> <property name="mbServerUrl" value="localhost:5674"/> <property name="cron" value="1 * * * * ? *"/> </topologySync> But if you make this change, a user need to have something like following configuration: <topologySync enable="true"> <!-- properties related to topology syncher --> <property name="className" value="org.apache.stratos.cloud.controller.ABC"/> <property name="connectionfactory.qpidConnectionfactory" value="amqp://admin:admin@clientID /carbon?brokerlist='tcp://localhost:5674'"/> <property name="cron" value="1 * * * * ? *"/> <property name="java.naming.factory.initial" value="org.wso2.andes.jndi.PropertiesFileInitialContextFactory"/> </topologySync> Let the community decide the best approach. > (I personally am not familiar with those other MBs in town.) >> > > For example, see [1] and [2]. Apache Axis2 uses only JMSListener class >> to support multiple message brokers. >> > >> > This is what I expect in the context of Apache Stratos also. As a start >> we can test Apache ActiveMQ and WSO2 Message Broker. >> > >> > I added https://issues.apache.org/jira/browse/STRATOS-52 to track this. >> > >> > [1] http://docs.wso2.org/wiki/display/ESB470/Configuring+JMS+Transport >> > [2] http://axis.apache.org/axis2/java/transports/jms.html >> > >> > >> > On Wed, Aug 14, 2013 at 4:31 PM, Nirmal Fernando < >> [email protected]> wrote: >> >> >> >> >> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <[email protected]> wrote: >> >> > >> >> > Hi all, >> >> > >> >> > >> >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <[email protected]> >> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> +1 for the approach! >> >> >> >> >> >> I think this is a good start to remove Message Broker features in >> Cloud Controller eventually. >> >> >> >> >> >> Perhaps we could modify the default implementation to be more >> generic as we could use AMQP. >> >> > >> >> > I would like to start working on this. (I think it's better to >> remove MB features from Cloud Controller and make it more light-weight. >> Right now it takes about 1 minute to start). >> >> > >> >> >> >> This is a PaaS and you do not do frequent restarts etc. Hence, IMO >> server start up time isn't a that critical concern. >> >> >> >> > We can then allow users to use any MB. Let's see whether we can use >> ActiveMQ and RabbitMQ >> >> > >> >> >> >> Your statement is misleading. We don't need to remove WSO2 MB features >> from CC in order to support other MBs. >> >> >> >> In fact the sole purpose of the email of mine was to introduce this >> extension point. >> >> IMO for the time being we just need to focus on using this extension >> point and provide support to other MBs. >> >> >> >> > I think this will not be a considerable effort. >> >> > >> >> > Suggestions? >> >> >> >> >> >> >> >> >> As you said, we could also have generic subscriber in ELB and >> Stratos Controller. >> >> >> >> >> >> I would like to see the code in Apache Git. :) >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Best Regards, >> >> >> >> >> >> >> >> >> On Wed, Aug 7, 2013 at 10:35 PM, Nirmal Fernando < >> [email protected]> wrote: >> >> >>> >> >> >>> Hi All, >> >> >>> >> >> >>> I worked on the $subject as and when I got time. And believe that >> I clearly separated out and provided an extension point to add any custom >> topology publisher. >> >> >>> >> >> >>> While doing this I had to change the current configuration of >> topology publisher as below: >> >> >>> >> >> >>> <topologySync enable="true"> >> >> >>> <!-- properties related to topology syncher --> >> >> >>> <property name="className" >> value="org.apache.stratos.cloud.controller.ABC"/> >> >> >>> <property name="mbServerUrl" value="localhost:5674"/> >> >> >>> <property name="cron" value="1 * * * * ? *"/> >> >> >>> </topologySync> >> >> >>> >> >> >>> >> >> >>> If you want to plug a new implementation instead of using the >> default implementation (WSO2MBTopologyPublisher), you should extend the >> following abstract class and configure it using a property (eg: <property >> name="className" value="org.apache.stratos.cloud.controller.ABC"/>). >> >> >>> >> >> >>> package org.apache.stratos.cloud.controller.interfaces; >> >> >>> >> >> >>> /** >> >> >>> * All custom implementations of Topology Publisher should extend >> this abstract class. >> >> >>> */ >> >> >>> public abstract class TopologyPublisher { >> >> >>> >> >> >>> /** >> >> >>> * This operation will be called once in order to initialize >> this publisher. >> >> >>> */ >> >> >>> public abstract void init(); >> >> >>> >> >> >>> /** >> >> >>> * When a message is ready to be published to a certain topic, >> this operation will be called. >> >> >>> * @param topicName name of the topic to be published. >> >> >>> * @param message message to be published. >> >> >>> */ >> >> >>> public abstract void publish(String topicName, String message); >> >> >>> >> >> >>> /** >> >> >>> * Cron expression which explains the frequency that the >> topology publishing happens. >> >> >>> * @return cron expression >> >> >>> */ >> >> >>> public abstract String getCron(); >> >> >>> >> >> >>> } >> >> >>> >> >> >>> You have the freedom to get any necessary parameters for your >> custom topology publisher implementation, due to the nature of the >> configuration shown above. Any number of properties are allowed and those >> can be retrieved via the object model. >> >> >>> >> >> >>> eg: >> >> >>> >> >> >>> TopologyConfig config = >> FasterLookUpDataHolder.getInstance() >> >> >>> .getTopologyConfig(); >> >> >>> String cron = >> config.getProperty(CloudControllerConstants.CRON_ELEMENT); >> >> >>> >> >> >>> With this extension point in hand, you can easily make Cloud >> Controller to publish topology information into another topic provider >> (Qpid etc.). >> >> >>> >> >> >>> I invite you to leverage this capability and help Apache Stratos >> to be compatible with other message broker implementations. >> >> >>> >> >> >>> Thanks. >> >> >>> >> >> >>> PS: We need the same kind of extensibility in the subscriber side. >> I will have a look on to it too. >> >> >>> >> >> >>> -- >> >> >>> Best Regards, >> >> >>> Nirmal >> >> >>> >> >> >>> C.S.Nirmal J. Fernando >> >> >>> Senior Software Engineer, >> >> >>> WSO2 Inc. >> >> >>> >> >> >>> Blog: http://nirmalfdo.blogspot.com/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Isuru Perera >> >> >> about.me/chrishantha >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Isuru Perera >> >> > about.me/chrishantha >> > >> > >> > >> > >> > -- >> > Isuru Perera >> > about.me/chrishantha >> > > > > -- > Isuru Perera > about.me/chrishantha > -- Best Regards, Nirmal C.S.Nirmal J. Fernando Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
