@Pamod & Ramith - Noted. Will not have a seperate config file for mqtt since we can re-use broker.xml configurations. Thanks.
@HasithaH - Thank you for sharing the qpid config information. I will study if these properties are used now and share the findings soon. On Fri, Nov 14, 2014 at 6:40 AM, Pamod Sylvester <[email protected]> wrote: > Hi Ramith, > > The main properties we would have is transport related, such as host and > the port the server will be bound to this will be included in the > broker.xml. > > in comparison to AMQP, in MQTT all the other properties will be > dynamically defined by the client (publisher or subscriber) when the > connection is established. I.e KEEPALIVE time, which will be defined during > the time client connects. > > What's meant is that we do not have much properties pre defined by the > server which will be applicable to all the clients. > > Thanks. > Pamod > > On Thu, Nov 13, 2014 at 11:43 PM, Ramith Jayasinghe <[email protected]> > wrote: > >> What are the properties we need to have for mqtt? >> >> On Thu, Nov 13, 2014 at 9:22 PM, Pamod Sylvester <[email protected]> wrote: >> >>> Hi HasithaA, >>> >>> For MQTT since the transport properties etc will be included in the >>> broker.xml we might not need a separate config (mqtt-config.xml) IMO. >>> Cause in MQTT most of the semantics are specified to the server during the >>> time it connects, AFAIK there're no other pre defined properties for it. >>> >>> Thanks, >>> Pamod >>> >>> On Thu, Nov 13, 2014 at 8:57 PM, Hasitha Amal De Silva < >>> [email protected]> wrote: >>> >>>> I am working on $subject and have identified different types of >>>> configuration parameters within our current pack in [1] >>>> <https://drive.google.com/file/d/0B1soNraLsHdmLW1manJFaDNDcjg/view?usp=sharing>. >>>> >>>> >>>> *Expectations from the revamp* >>>> >>>> - To maintain and unify all MB specific configurations through a >>>> single access point with a uniform access pattern. >>>> >>>> >>>> - To use more meaningful names for properties. >>>> >>>> >>>> - To organize properties in a sensible hierarchical manner for >>>> intuitive reference. >>>> >>>> >>>> - Separate external configurations coming from qpid sources >>>> >>>> >>>> - Verify and remove unused configurations (e.g. hector and >>>> zookeeper related ones) and cluster enabling from "andes-config.xml" >>>> (cos >>>> its now done with hazelcast) >>>> >>>> >>>> - Add new configurations introduced in v3.0.0 >>>> >>>> >>>> *Current status of configuration files * >>>> >>>> According to the new model the main "broker.xml" will contain links to >>>> the following sub configuration files : >>>> >>>> 1. mqtt-config.xml (@Pamod - Need to check what we have to include >>>> in this. for now this is empty.) >>>> 2. qpid-config.xml >>>> 3. virtualhosts.xml >>>> >>>> Please refer attached xml files for modified configuration properties. >>>> These are still a work-in-progress. Do share your feedback on how it can be >>>> further improved. >>>> >>>> *Removing unused properties* >>>> >>>> I have removed properties that are read but not used anywhere in code. >>>> But there's still a few more to carefully remove. >>>> >>>> @HasithaH - I noticed that even a few qpid properties are obsolete. >>>> e.g. "advanced.enableJMSXUserID" in "qpid-config.xml". Should we keep them >>>> as-is to respect qpid's seperation, or remove after verifying ? >>>> >>>> >>>> *Naming conventions * >>>> >>>> I have attempted to break down properties into semantic parent tags as >>>> much as possible. e,g, instead of using "andesContextStore" in >>>> virtualhosts.xml we can just use "contextStore". instead of using >>>> "slotWindowSize" I have added a slot tag in which the "windowSize" property >>>> resides. >>>> >>>> The camelCase naming pattern is used throughout. There are few misses >>>> in attached configs, will be correcting them. >>>> >>>> >>>> *New Properties (Code must be modified to act upon these)* >>>> >>>> - virtualhost.xml : "virtualhost.nodeID" - To override the default >>>> node ID generated through hazelcast (IP + UUID). >>>> >>>> >>>> - broker.xml : "transports.minaEnabled" and >>>> "transports.nettyEnabled" - To disable the two transports selectively >>>> in a >>>> scenario that only one is being used (only mqtt or only amqp*)* >>>> >>>> *Explanatory comments* >>>> >>>> I have added purposeful comments for some. This is still in progress. >>>> >>>> *Access Pattern* >>>> >>>> Right now configuration properties are being accessed mainly from the >>>> "org.wso2.andes.server.configuration.ServerConfiguration" class. This class >>>> was originally from qpid and has been modified to include our >>>> configurations too. The andes-virtualhosts.xml is read from the >>>> "business-messaging" component. >>>> >>>> The new model exposes all these properties through a Singleton >>>> container and it is based on apache commons Configuration features [2] >>>> <http://www.code-thrill.com/2012/05/configuration-that-rocks-with-apache.html> >>>> [3] <http://java.dzone.com/articles/managing-configurations-apache>. >>>> >>>> - Given that "broker.xml" contains links to the sub config files, >>>> it is loaded as the primary configuration. >>>> >>>> >>>> - All sub configuration files are then combined reading through the >>>> "links" tag in "broker.xml" >>>> >>>> >>>> - Since the CompositeConfiguration class allows us to access any >>>> property from all the files after combining, We can then use XPath to >>>> read >>>> from the loaded CompositeConfiguration object. >>>> >>>> All configuration properties are defined using an Enum format where >>>> each property has the following attributes : >>>> >>>> - keyInFile : xpath expression to find the property from >>>> CompositeConfiguration object. >>>> >>>> >>>> - dataType : expected datatype of the property >>>> >>>> >>>> - defaultValue : specified default value for the property in case >>>> it is not set in the files. >>>> >>>> This enum-oriented design was based on [4] >>>> <http://sett.ociweb.com/sett/settNov2012.html>. IMO it reduces code >>>> duplication and gives a cleaner way to access properties than using string >>>> literals. >>>> >>>> Given this design, a property can be parsed to its expected type and >>>> accessed by anywhere with the following statement : >>>> >>>> >>>> AndesConfigurationManager.getInstance().getConfigurationValue(BrokerConfiguration.PERFORMANCE_TUNING_SLOTS_WINDOW_SIZE) >>>> >>>> Refer attached image "ConfigAccessPattern_MB_3_0_0.png" for more >>>> details. >>>> >>>> *Testing* >>>> >>>> Since we use enums to define the properties, A single test case that >>>> iterates through all properties and reads them should be sufficient to >>>> verify if any properties are faulty. >>>> >>>> However, key MB functionalities should be also verified through >>>> existing test suite to make sure nothing unexpected is broken. >>>> >>>> *TODO* >>>> >>>> Refactor "andes" and "business-messaging" code to use the new Access >>>> Pattern. Remove obsolete code. >>>> >>>> Implement actions based on new configuration properties. >>>> >>>> Dig into qpid source and identify unused but read properties and remove >>>> as necessary >>>> >>>> Add automated test case for configuration verification. >>>> >>>> Review and finalize comments in the configuration files and follow up >>>> with doc team. >>>> >>>> [1] : >>>> https://drive.google.com/file/d/0B1soNraLsHdmLW1manJFaDNDcjg/view?usp=sharing >>>> <https://drive.google.com/a/wso2.com/file/d/0B1XfuoFd-MhEeWxiNkFNNk5NMzg/view?usp=sharing> >>>> [2] : >>>> http://www.code-thrill.com/2012/05/configuration-that-rocks-with-apache.html >>>> [3] : http://java.dzone.com/articles/managing-configurations-apache >>>> [4] : http://sett.ociweb.com/sett/settNov2012.html >>>> >>>> -- >>>> Cheers, >>>> >>>> Hasitha Amal De Silva >>>> Software Engineer >>>> Mobile : 0772037426 >>>> Blog : http://devnutshell.tumblr.com/ >>>> WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. ) >>>> >>> >>> >>> >>> -- >>> *Pamod Sylvester * >>> *Senior Software Engineer * >>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>> email: [email protected] cell: +94 77 7779495 >>> >> >> >> >> -- >> Ramith Jayasinghe >> Technical Lead >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> E: [email protected] >> P: +94 777542851 >> >> > > > -- > *Pamod Sylvester * > *Senior Software Engineer * > Integration Technologies Team, WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 7779495 > -- Cheers, Hasitha Amal De Silva Software Engineer Mobile : 0772037426 Blog : http://devnutshell.tumblr.com/ WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. )
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
