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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
