Hi Hasitha, Personally, I like to separate store configs from virtual-host. Virtualhost is a AMQP concept (according to it, each vHost should have separate stores). Now we cannot apply it to the whole broker. Moreover, we do not support multiple virtual-hosts as per current impl (Spec violation? To business, not so important)
Thanks On Thu, Nov 13, 2014 at 9:18 PM, Hasitha Hiranya <[email protected]> wrote: > Hi Hasitha, > > This is a list of configs I have found out digging into internet related > to Qpid. > Resending info as they are useful for you now. > Sewwandi knows some context on this as well. > > Hi Team, > > This is a try to resolve https://wso2.org/jira/browse/MB-407. > > I did a search to find out what are the unfamiliar configurations in > andes-config.xml file. We need to know them, test if they work, consider if > they are valid, remove if not relevant (specially the highlighted ones). > > @Prabath, > *I also saw a config for OOM controlling. Please note. * > > Below are the findings. > > > > == Extended Configuration through config.xml == > > The config.xml contains the extended configuration information associated > with > the Qpid Java Broker. > > === The JMX Management Console Configuration === > > The management console configuration can be setup by editing the > management > child element of the broker configuration. The available options are: > > 1. enabled > 2. jmxport > 3. security-enabled > > Setting enabled to "true" will enable the JMX Management Console support. > And, > changing the jmxport will make it possible to connect using a different > port. > Setting the security-enabled option to "true" will make it possible to use > SASL > Authentication. > > Advanced security configuration is made effective once the > security-enabled is > set to "true". Further customization is explained in the Security > Configuration > section below. > > === Connector Configuration === > > The connetor configuration element manages connections to/from the Java > Broker. > Among the various options available are: > > 1. ssl > 2. qpidnio > 3. protectio > 4. bind > 5. port > 6. sslport > 7. socketReceiveBuffer > 8. socketSendBuffer > 9. processors > 10. tcpNoDelay > > The ssl and *protecio* elements are discussed below. The port corresponds > to the > port in which the non-secure Java Broker runs. The *sslport* corresponds > to the > port in which the secure Java Broker runs. > > The *socketReceiveBuffer* and the *socketSendBuffer* sizes (in bytes) are > configured > using the respective elements. Setting *qpidnio* to "true" will setup a > multithreaded MINA socket acceptor that will make an attempt to boost the > performance by simultaneously allowing reading from and writing to a > socket. > > Processors represent the the number of SocketProcessors you wish to > create. And, > *bind* represents the ip-address to bind to. In addition to that, you can > enable > TCP NoDelay by setting *tcpNoDelay* to "true'. > > Please note that the element transport is no longer used. > > ==== SSL Configuration ==== > > The SSL configuration can be setup by editing the connector child > element's ssl > child. The available options are: > > 1. enabled > 2. sslOnly > 3. keystorePath > 4. keystorePassword > > The enabled option controls whether SSL is enabled or not. Setting this to > "true" will enable SSL support. The sslOnly option will decide whether SSL > will > operate in parallel with non-SSL ports or not. The remaining options are on > setting up an SSL keystore. Please note that the keystore password is seen > in > clear text in the config.xml. Do take necessary precautions when setting > this > option. > > ==== Protect I/O Configuration ==== > > *This feature is meant for the protection of the Java Broker from running > out of* > *memory due to runnaway clients or non-responsive clients*. The > protection is > achieved by limiting the data written to or read from a pending queue. The > enabled option controls whether I/O protection is in place or not. To > enable, > set the enabled element's value to "true". > > === Security Configuration === > > There are various sub sections under the security configuration, which > are: > > 1. principal-databases > 2. access > 3. jmx > > More on principal-databases and jmx are discussed below. The access > element is > used to set the ACLPlugin implementation which is capable of controlling > access. > This can be set through the class element. > > ==== Principal Databases ==== > > The *principal-databases* section contains definitions of principal > databases. An > example of a principal database is a set of Base64 encoded MD5 hashes, > which is > stored on a file, which can be used for authentication via the > CRAM-MD5-Hashed > SASL authentication mechanism. > > *(We have put > org.wso2.carbon.andes.authentication.andes.CarbonBasedPrincipalDatabase > here. I am not aware what it is??)* > > Among various options a principal-database configuration posses are: > > 1. name > 2. class > 3. attributes > > The name of the resource is identified by name. The class is the Java class > capable of handling the resource. The attribute passwordFile will have a > value > of which is the path to the password database file. An example password > database > file is ../etc/passwd, which contains plain-text password. > > More information on this section can be found online at, > http://cwiki.apache.org/qpid/qpid-design-authentication.html > > ==== JMX Security Configuration ==== > > The *JMX Security* configuration is used to specify the access > restrictions, which > is written on a file (../etc/jmxremote.access is an example). The path to > this > file is specified in access. The principal-database to be used can also be > configured. Among the available options are: > > 1. access > 2. principal-database > > === Virtual Host Configuration === > > The virtual hosts are configured through the virtualhosts element. This > has two > major subsections: > > 1. directory > 2. virtualhost > > The directory is the* path to the directory in which extended virtual > host* > *configurations are present*. An example is ../etc/vitualhosts. More on > the > virtual host directory is found below in the Virtual Host Directory section > below. > > Under the virtualhost subsection there are various properties that can be > set > through the config.xml. They are: > > 1. name > 2. store > 3. housekeeping > > The name will represent the corresponding name which recognizes the > virtualhost > in both the config.xml as well as the virtual host directory. The store is > a > class that represents the type of store implemented. The housekeeping > element is > used to set the expiredMessageCheckPeriod used by housekeeping timers. > > === Advanced Configuration === > > The Advanced Configuration section is not intended to be customized by a > user as > it might lead the broker into an unstable state. For more information > please > contact the developer list. > > == The Virtual Hosts Directory == > > TBD > > Thanks > > 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. ) >> > > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
