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