Hi Robert, Thanks for the detail. However, I believe that this might not be required to be a part of the README. However, this provides an excellent basis for discussing there purpose. I would like to know why "filterchain enableExecutorPool="true"/>" is present if it never should be false?
Hi devs, I will modify the README as required considering various suggestions made by Martin regarding the "advanced" section of the config.xml. I'm attaching herewith the partially completed version. Please do let me know of any improvements that can be done. Thanks, Senaka On Tue, May 20, 2008 at 6:05 PM, Robert Greig <[EMAIL PROTECTED]> wrote: > 2008/5/20 Senaka Fernando <[EMAIL PROTECTED]>: > > > Thanks for the valuable guidelines. I'm almost done writing the README > for > > the config.xml. > > Great work! > > > However, I'm yet to understand the, > > > > <advanced> > > <filterchain enableExecutorPool="true"/> > > <enablePooledAllocator>false</enablePooledAllocator> > > <enableDirectBuffers>false</enableDirectBuffers> > > <framesize>65535</framesize> > > <compressBufferOnQueue>false</compressBufferOnQueue> > > <enableJMSXUserID>false</enableJMSXUserID> > > </advanced> > > > > section. As it seems it is a bit advanced to figure out. :)... > > OK, from the top - many of these are actually MINA specific - if > anyone spots that I am talking nonsense please jump in and correct me: > > enableExecutorPool specifies whether to add a threadpool filter to the > filterchain - basically means that the I/O is done in a separate > thread from the processing. This really should never be set to false. > > pooled allocator means that MINA will pool byte buffers. Testing has > shown that this counterproductive when using heap buffers (see next > point) > > direct buffers are the NIO direct byte buffers - as opposed to heap > buffers. In theory they are supposed to be faster but on the operating > systems and JVMs that we have tested (RHEL 3 and 4, sun and BEA) we > find that heap buffers are better. YMMV. > > framesize - the maximum framesize the broker will use for AMQP frames. > Messages bigger than this size will be fragmented into frames of this > size. It may be worth increasing the size to increase throughput if > you send messages a little bit bigger than this but obviously this > needs careful testing etc etc > > compressBufferOnQueue - by default, for performance, byte buffers > representing data read off the network are not compressed. This is > sensible if the data is just about to go straight out to a client. > However it does mean that the memory usage will be high (see the > comments earlier about the socket buffer sizes) so setting this to > true should reduce memory usage particularly if you have slow clients. > > JMSXUserId - no idea I'm afraid. > > > Also, there are two elements configuring virtualhosts. I would like to > know > > how this works out. > > Anything specific? > > Not sure myself about the virtualhosts directory - is it perhaps where > to look for the virtualhosts xml files? > > RG >
= Qpid Java Broker User Guide = This guide serves as a basic introduction to using the Qpid Java Broker. For more up-to-date and advanced information please contact the Qpid Developer Mailing list ([email protected]). == Starting the Broker == The Qpid Java Broker can be started using one of the two following methods on a Linux environment: 1. running qpid-server 2. running qpid.start On a MS Windows environment, you can start the Qpid Java Broker using the following method. 1. running qpid-server.bat == Basic Start-up Parameters == The Basic Parameters that can be passed during the start-up of the Qpid Java Broker are as follows. -b,--bind <bind> bind to the specified address. Overrides any value in the config file -c,--config <file> use given configuration file -h,--help print this message -l,--logconfig <logconfig> use the specified log4j xml configuration file. By default looks for a file named log4j.xml in the same directory as the configuration file -m,--mport <mport> listen on the specified management port. Overrides any value in the config file -p,--port <port> listen on the specified port. Overrides any value in the config file -v,--version print the version information and exit -w,--logwatch <logwatch> monitor the log file configuration file for changes. Units are seconds. Zero means do not check for changes. The configuration files can be found in ../etc/. Also, the default values for the various parameters discussed above are as follows: -b,--bind <bind> 0.0.0.0 -c,--config <file> $QPID_HOME/etc/config.xml -l,--logconfig <logconfig> $QPID_HOME/etc/log4j.xml -m,--mport <mport> 8999 -p,--port <port> 5672 -w,--logwatch <logwatch> 0 == 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. 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
