On Thu, Aug 15, 2013 at 6:20 PM, Isuru Perera <[email protected]> wrote:
> > > > On Thu, Aug 15, 2013 at 3:11 AM, Nirmal Fernando > <[email protected]>wrote: > >> >> >> >> 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. >> > I don't understand how this discourages new users. As I mentioned earlier, > we will be providing all the required configurations with docs. > You'll realize it eventually. > > 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> >> > This is much more cleaner to me than just specifying some class with all > configuration details hidden. I'm thinking of a similar configuration for > subscriber also. > > I think the current way of configuring the subscriber is also really > confusing. There are two different ways to configure the subscriber in SC > and ELB. For ELB you need to edit the loadbalancer.conf and for SC you have > to use a startup parameter. As I remember, For ELB it's mb_server_url and > for SC it's mb.server.ip. SC also has the same config in > cartridge-config.properties as well and user need to have same config in > both places > > We need to fix these inconsistencies. > > Yes, yes. Any Software should be evolved by time, you can't hold a release till it reach perfection (if you do hold, you will never able to do a release). This is my last email to this thread, I've more important work than arguing here. > >> Let the community decide the best approach. >> > +1. May be we can start a new discussion thread. > >> (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/ >> > > > > -- > Isuru Perera > about.me/chrishantha > -- Best Regards, Nirmal C.S.Nirmal J. Fernando Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
