[jboss-cvs] JBossAS SVN: r97817 - in projects/docs/enterprise/5.0: Installation_Guide/en-US and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Dec 14 18:59:46 EST 2009
Author: laubai
Date: 2009-12-14 18:59:45 -0500 (Mon, 14 Dec 2009)
New Revision: 97817
Modified:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/AOP.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml
projects/docs/enterprise/5.0/Installation_Guide/en-US/Introduction.xml
Log:
JIRA corrections.
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/AOP.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/AOP.xml 2009-12-14 23:53:44 UTC (rev 97816)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/AOP.xml 2009-12-14 23:59:45 UTC (rev 97817)
@@ -152,7 +152,7 @@
4. <bind pointcut="* com.mc.billing.*->*(..)">
5. <interceptor class="com.mc.Metrics"/>
-6. </bind >]]></programlisting>
+6. </bind >
</programlisting>
<para>
@@ -246,7 +246,7 @@
it on startup you need to edit some configuration files.
</para>
<para>
- In JBoss Enterprise Application Platform 5 the AspectManager Service is configured using a JBoss Microcontainer bean. The configuration file is <literal>jboss-5.x.x.GA/server/xxx/conf/aop.xml</literal>. The AspectManager Service is deployed with the following xml:
+ In JBoss Enterprise Application Platform 5 the AspectManager Service is configured using a JBoss Microcontainer bean. The configuration file is <literal>jboss-as/server/xxx/conf/bootstrap/aop.xml</literal>. The AspectManager Service is deployed with the following xml:
</para>
<programlisting><![CDATA[
<bean name="AspectManager" class="org.jboss.aop.deployers.AspectManagerJDK5">
@@ -363,7 +363,7 @@
<section>
<title>Improving Loadtime Performance in tje JBoss Enterprise Application Platform Environment</title>
<para>
- The same rules apply to the JBoss Enterprise Application Platform for tuning loadtime weaving performance as standalone Java. Switches such as pruning, optimized, include and exclude are configured through the <filename>jboss-aop.deployer/META-INF/jboss-service.xml</filename> file talked about earlier in this chapter.
+ The same rules apply to the JBoss Enterprise Application Platform for tuning loadtime weaving performance as standalone Java. Switches such as pruning, optimized, include and exclude are configured through the <filename>jboss-5.x.x.GA/server/xxx/conf/aop.xml</filename> file talked about earlier in this chapter.
</para>
</section>
<section>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml 2009-12-14 23:53:44 UTC (rev 97816)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Messaging.xml 2009-12-14 23:59:45 UTC (rev 97817)
@@ -2,495 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
]>
<chapter id="messaging"><title>JBoss Messaging</title>
-
-<para>
- <indexterm><primary>JBoss Messaging</primary><secondary>about</secondary></indexterm>
- <indexterm><primary>JMS</primary><see>JBoss Messaging</see></indexterm>
-JBoss Messaging is the new enterprise messaging system from JBoss. It is a complete rewrite of JBossMQ, the legacy JBoss JMS provider. It is the default JMS provider on JBoss Enterprise Application Platform 5. <!-- Production support is already available through JBoss EAP 4.3, and we offer developer support for JBoss 4.2.x. --></para>
-<para>JBoss Messaging is a high Performance JMS 1.1 compliant implementation integrated with JBoss Transactions. It also offers:</para>
-<itemizedlist>
- <listitem>
- <para>
- Clustered Queues and Topics by Default
- </para>
- </listitem>
- <listitem>
- <para>
- Intelligent Message Redistributions
- </para>
- </listitem>
- <listitem>
- <para>
- Transparent Failover
- </para>
- </listitem>
- <listitem>
- <para>
- In memory message Replication
- </para>
- </listitem>
-</itemizedlist>
-
-<!--<para>
- JBoss Messaging will be the default JMS provider in later versions of JBoss Enterprise Application Platform, and JBoss Service Integration Platform. It is also the default JMS provider in JBoss Application Server 5, and is the default JMS provider for JBoss ESB.</para> -->
-<para>JBoss Messaging is an integral part of Red Hat's strategy for messaging.</para>
-<!--<para>Compared with JBossMQ, JBoss Messaging offers improved performance in both single node and clustered environments.</para>
-<para>JBoss Messaging also features a much better modular architecture that will allow us to add more features in the future.</para> -->
-<para>JBoss Messaging provides an open source and standards-based messaging platform that brings enterprise-class messaging to the mass market. It also implements a high performance, robust messaging core that is designed to support the largest and most heavily utilized SOA, enterprise service buses (ESBs) and other integration needs ranging from the simplest to the highest network demands.</para>
-<para>It allows you to smoothly distribute your application load across your cluster, intelligently balancing and utilizing each nodes CPU cycles, with no single point of failure. This provides a highly scalable and performance implementation for clustering.</para>
-<para>JBoss Messaging includes a JMS front-end to deliver messaging in a standards-based format as well as being designed to be able to support other messaging protocols in the future.</para>
-<!--<para>JBoss Messaging is committed to AMQP ( <ulink url="http://www.amqp.org/">AMQP</ulink>)- the new messaging standard from Red Hat and others. Later versions of JBoss Messaging will support AMQP, and JBoss Messaging is focused on becoming the premier AMQP Java broker.</para>-->
-
-<section><title>Configuring JBoss Messaging</title>
-
-<para>
- The JBoss Messaging service configuration is spread among several configuration files. Depending on the functionality provided by the services it configures, the configuration data is distributed between <filename><JBOSS_HOME>/server/<configuration>/deploy/messaging-service.xml, remoting-service.xml, connection-factories-service.xml, destinations-service.xml and xxx-persistence-service.xml</filename> (where <literal>xxx</literal> is the name of your database). The default will be <filename>hsqldb-persistence-service.xml</filename> for the hsqldb database.
-</para>
-
-<section><title>Configuring the SecurityStore</title>
-<para>
- SecurityStore is a pluggable object, and it has a default implementation in <filename>messaging-service.xml</filename>:
-</para>
-<!--<programlisting role="XML"><server>
- <mbean code="org.jboss.jms.server.security.SecurityMetadataStore"
- name="jboss.messaging:service=SecurityStore">
-
- <attribute name="DefaultSecurityConfig">
- <security>
- <role name="guest" read="true" write="true" create="true"/>
- </security>
- </attribute>
-
- <attribute name="SecurityDomain">java:/jaas/messaging</attribute>
-
- <attribute name="SuckerPassword">CHANGE ME!!</attribute>
-</mbean>
-...
-...file truncated..
-</programlisting>-->
-<programlisting>
-<depends optional-attribute-name="SecurityStore"
- proxy-type="org.jboss.jms.server.SecurityStore">
- jboss.messaging:service=SecurityStore
- </depends>
-</programlisting>
-<para>
- This implementation points the ServerPeer to <code>jboss.messaging:service=SecurityStore</code>, which is defined in the <filename>messaging-jboss-beans.xml</filename> file.
-</para>
-</section>
-
-<section><title>SecurityStore Attributes</title>
- <para>The following are SecurityStore attributes from the <filename>messaging-jboss-beans.xml</filename> file above.
-</para>
-<formalpara>
-<title>DefaultSecurityConfig</title>
- <para>
- Default security configuration is used when the security configuration for a specific queue or topic has not been overridden in the destination's deployment descriptor. It has exactly the same syntax and semantics as in JBossMQ.
- </para>
-</formalpara>
- <para>
- The DefaultSecurityConfig attribute element should contain one <security> element. The <security> element can contain multiple <role> elements. Each <role> element defines the default access for that particular role.
- </para>
- <para>
- If the read attribute is true then that role will be able to read (create consumers, receive messaages or browse) destinations by default. If the write attribute is true then that role will be able to write (create producers or send messages) to destinations by default. If the create attribute is true then that role will be able to create durable subscriptions on topics by default.
- </para>
-
-<formalpara>
-<title>SecurityDomain</title>
- <para>
- The JAAS security domain to be used by this server peer.
- </para>
-</formalpara>
-
-<formalpara><title>SuckerPassword</title>
- <para>
- This defines how the SecurityStore will authenticate the sucker user (<literal>JBM.SUCKER</literal>).
- </para>
-</formalpara>
-
-
-
-</section>
-
-</section>
-
-<section><title>Configuring the ServerPeer</title>
-<para>
- The <classname>ServerPeer</classname> is the heart of the JBoss Messaging JMS. All JBoss Messaging services are rooted at the server peer and the server's configuration resides in the <filename>messaging-service.xml</filename> configuration file. An example of a Server Peer configuration is presented below, though not all values for the server peer's attributes are specified in the example.
-</para>
-
-<programlisting role="XML"><!-- ServerPeer MBean configuration
- ============================== -->
-
- <mbean code="org.jboss.jms.server.ServerPeer"
- name="jboss.messaging:service=ServerPeer"
- xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
-
- <!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->
-
- <attribute name="ServerPeerID">${jboss.messaging.ServerPeerID:0}</attribute>
-
- <!-- The default JNDI context to use for queues when they are deployed without specifying one -->
-
- <attribute name="DefaultQueueJNDIContext">/queue</attribute>
-
- <!-- The default JNDI context to use for topics when they are deployed without specifying one -->
-
- <attribute name="DefaultTopicJNDIContext">/topic</attribute>
-
- <attribute name="PostOffice">jboss.messaging:service=PostOffice</attribute>
-
- <!-- The default Dead Letter Queue (DLQ) to use for destinations.
- This can be overridden on a per destinatin basis -->
-
- <attribute name="DefaultDLQ">jboss.messaging.destination:service=Queue,name=DLQ</attribute>
-
- <!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).
- This can be overridden on a per destinatin basis -->
-
- <attribute name="DefaultMaxDeliveryAttempts">10</attribute>
-
- <!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis -->
-
- <attribute name="DefaultExpiryQueue">
- jboss.messaging.destination:service=Queue,name=ExpiryQueue
- </attribute>
-
- <!-- The default redelivery delay to impose. This can be overridden on a per destination basis -->
-
- <attribute name="DefaultRedeliveryDelay">0</attribute>
-
- <!-- The periodicity of the message counter manager enquiring on queues for statistics -->
-
- <attribute name="MessageCounterSamplePeriod">5000</attribute>
-
- <!-- The maximum amount of time for a client to wait for failover to start on the server side after
- it has detected failure -->
-
- <attribute name="FailoverStartTimeout">60000</attribute>
-
- <!-- The maximum amount of time for a client to wait for failover to complete on the server side after
- it has detected failure -->
-
- <attribute name="FailoverCompleteTimeout">300000</attribute>
-
- <attribute name="StrictTck">false</attribute>
-
- <!-- The maximum number of days results to maintain in the message counter history -->
-
- <attribute name="DefaultMessageCounterHistoryDayLimit">-1</attribute>
-
- <!-- The name of the connection factory to use for creating connections between nodes to pull messages -->
-
- <attribute name="ClusterPullConnectionFactoryName">
- jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
- </attribute>
-
- <!-- When redistributing messages in the cluster. Do we need to preserve the order of messages received
- by a particular consumer from a particular producer? -->
-
- <attribute name="DefaultPreserveOrdering">false</attribute>
-
- <!-- Max. time to hold previously delivered messages back waiting for clients to reconnect after failover -->
-
- <attribute name="RecoverDeliveriesTimeout">300000</attribute>
-
- <!-- The password used by the message sucker connections to create connections.
- THIS SHOULD ALWAYS BE CHANGED AT INSTALL TIME TO SECURE SYSTEM
- <attribute name="SuckerPassword"></attribute>
- -->
-
- <!-- The name of the server aspects configuration resource
- <attribute name="ServerAopConfig">aop/jboss-aop-messaging-server.xml</attribute>
- -->
- <!-- The name of the client aspects configuration resource
- <attribute name="ClientAopConfig">aop/jboss-aop-messaging-client.xml</attribute>
- -->
-
- <depends optional-attribute-name="PersistenceManager">jboss.messaging:service=PersistenceManager</depends>
-
- <depends optional-attribute-name="JMSUserManager">jboss.messaging:service=JMSUserManager</depends>
-
- <depends>
- jboss.messaging:service=Connector,transport=bisocket
- </depends>
- <depends optional-attribute-name="SecurityStore"
- proxy-type="org.jboss.jms.server.SecurityStore">
- jboss.messaging:service=SecurityStore
- </depends>
-</mbean>
-...
-</programlisting>
-
-</section>
-
-<section><title>Server Attributes</title>
-<para>
- This section discusses the MBean attributes of the ServerPeer MBean.
-</para>
-
-<section><title>ServerPeerID</title>
-<para>
-The <classname>ServerPeerID</classname> is the unique ID of the server peer that every node you deploy <emphasis>must</emphasis> have. This applies whether the different nodes form a cluster, or are only linked via a message bridge. The ID must be a valid integer.
-</para>
-<note>
- <para>
- The scope of <classname>ServerPeerID</classname> is currently from 0 to 255. <!--Future releases will see this enlarged to 1023 -->
- </para>
-</note>
-</section>
-
-<!--Up to here for editing EAP 5-->
-
-<section><title>DefaultQueueJNDIContext</title>
- <para>
- The default JNDI context to use when binding queues. Defaults to <literal>/queue</literal>.
- </para>
-</section>
-<section><title>DefaultTopicJNDIContext</title>
- <para>
- The default JNDI context to use when binding topics.wa Defaults to <literal>/topic</literal>.
- </para>
-</section>
-<section><title>PostOffice</title>
- <para>
- This is the post office that the ServerPeer uses. You will not normally need to change this attribute. The post office is responsible for routing messages to queues and maintaining the mapping between addresses and queues.
- </para>
-</section>
-<section><title>DefaultDLQ</title>
- <para>
- This is the name of the default DLQ (Dead Letter Queue) the server peer will use for destinations. The DLQ can be overridden on a per destination basis - see the destination MBean configuration for more details. A DLQ is a special destination where messages are sent when the server has attempted to deliver them unsuccessfully more than a certain number of times. If the DLQ is not specified at all then the message will be removed after the maximum number of delivery attempts. The maximum number of delivery attempts can be specified using the attribute DefaultMaxDeliveryAttempts for a global default or individually on a per destination basis.
- </para>
-</section>
-<section><title>DefaultMaxDeliveryAttempts</title>
- <para>
- The default for the maximum number of times delivery of a message will be attempted before sending the message to the DLQ, if configured.
- </para>
- <para>The default value is 10.This value can also be overridden on a per destination basis.
- </para>
-</section>
-<section><title>DefaultExpiryQueue</title>
- <para>
- This is the name of the default expiry queue the server peer will use for destinations. The expiry can be overridden on a per destination basis - see the destination MBean configuration for more details. An expiry queue is a special destination where messages are sent when they have expired. Message expiry is determined by the value of Message::getJMSExpiration() If the expiry queue is not specified at all then the message will be removed after it is expired.
- </para>
-</section>
-<section><title>DefaultRedeliveryDelay</title>
- <para>
- When redelivering a message after failure of previous delivery it is often beneficial to introduce a delay perform redelivery in order to prevent thrashing of delivery-failure, delivery-failure etc.
- </para>
- <para>
- The default value is 0 which means there will be no delay.
- </para>
- <para>
- Change this if your application could benefit with a delay before redelivery. This value can also be overridden on a per destination basis.
- </para>
-</section>
-<section><title>MessageCounterSamplePeriod</title>
- <para>
- Periodically the server will query each queue to gets its statistics. This is the period.
- </para>
- <para>
- The default value is 10000 milliseconds.
- </para>
-</section>
-<section><title>FailoverStartTimeout</title>
- <para>
- The maximum number of milliseconds the client will wait for failover to start on the server side when a problem is detected.
- </para>
- <para>
- The default value is 60000 (one minute).
- </para>
-</section>
-<section><title>FailoverCompleteTimeout</title>
- <para>
- The maximum number of milliseconds the client will wait for failover to complete on the server side after it has started. The default value is 300000 (five minutes).
- </para>
-</section>
-<section><title>DefaultMessageCounterHistoryDayLimit</title>
- <para>
- JBoss Messaging provides a message counter history which shows the number of messages arriving on each queue of a certain number of days. This attribute represents the maxiumum number of days for which to store message counter history. It can be overridden on a per destination basis.
- </para>
-</section>
-<section><title>ClusterPullConnectionFactory</title>
- <para>
- The name of the connection factory to use for pulling messages between nodes.
- If you wish to turn off message sucking between queues altogether, but retain failover, then you can ommit this attribute altogether.
- </para>
-</section>
-<section><title>DefaultPreserveOrdering</title>
- <para>
- If true, then strict JMS ordering is preserved in the cluster. See the cluster configurations section for more details. Default is false.
- </para>
-</section>
-<section><title>RecoverDeliveriesTimeout</title>
- <para>
- When failover occurs, already delivered messages will be kept aside, waiting for clients to reconnect. In the case that clients never reconnect (e.g. the client is dead) then eventually these messages will timeout and be added back to the queue. The value is in ms. The default is 5 mins.
- </para>
-</section>
-<section><title>SuckerPassword</title>
- <para>
- JBoss Messaging internally makes connections between nodes in order to redistribute messages between clustered destinations. These connections are made with the user name of a special reserved user. On this parameter you define the password used as these connections are made. You will need to configure the Sucker password in the SecurityStore <literal>mbean</literal> configuration file (<filename>messaging-jboss-beans.xml</filename>), the ServerPeer Sucker password will be ignored.
- </para>
-<warning><title>Warning</title>
-<para>This must be specified at install time, or the default password will be used. Any one who then knows the default password will be able to gain access to any destinations on the server. This value <emphasis>must</emphasis> be changed at install time.</para>
-</warning>
-</section>
-<section><title>StrictTCK</title>
- <para>Set to true if you want strict JMS TCK semantiocs
- </para>
-</section>
-<section><title>Destinations</title>
- <para>
- Returns a list of the destinations (queues and topics) currently deployed.
- </para>
-</section>
-<section><title>MessageCounters</title>
- <para>
- JBoss Messaging provides a message counter for each queue.
- </para>
-</section>
-<section><title>MessageStatistics</title>
- <para>
- JBoss Messaging provides statistics for each message counter for each queue.
- </para>
-</section>
-<section><title>SupportsFailover</title>
-<para>
- Set to false to prevent server side failover occurring in a cluster when a node crashes.
-</para>
-</section>
-<section><title>PersistenceManager</title>
- <para>
- This is the persistence manager that the ServerPeer uses. You will not normally need to change this attribute.
- </para>
-</section>
-<section><title>JMSUserManager</title>
- <para>
- This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
- </para>
-</section>
-<section><title>SecurityStore</title>
- <para>
- This is the pluggable SecurityStore. If you redefine this SecurityStore, notice it will need to authenticate the MessageSucker user ("JBM.SUCKER") with all the special permissions required by clustering.
- </para>
-</section>
-
-</section>
-
-<section><title>MBean operations of the ServerPeer MBean</title>
-
-
-<section><title>DeployQueue</title>
- <para>
- This operation lets you programmatically deploy a queue. There are two overloaded versions of this operation. If the queue already exists but is undeployed it is deployed. Otherwise it is created and deployed. The <literal>name</literal> parameter represents the name of the destination to deploy. The <literal>jndiName</literal> parameter (optional) represents the full jndi name where to bind the destination. If this is not specified then the destination will be bound in <literal><DefaultQueueJNDIContext>/<name></literal>.
- </para>
- <para>
- The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the paging parameters mean.
- </para>
-</section>
-<section><title>UndeployQueue</title>
- <para>
- This operation lets you programmatically undeploy a queue.
- The queue is undeployed but is NOT removed from persistent storage.
- This operation returns true if the queue was successfull undeployed. otherwise it returns false.
- </para>
-</section>
-<section><title>DestroyQueue</title>
- <para>
- This operation lets you programmatically destroy a queue.
- The queue is undeployed and then all its data is destroyed from the database.</para>
-
-<warning><title>Warning</title>
-<para>Be cautious when using this method since it will delete all data for the queue.</para>
-</warning>
- <para>
- This operation returns true if the queue was successfully destroyed. otherwise it returns false.
- </para>
-
-</section>
-<section><title>DeployTopic</title>
- <para>
- This operation lets you programmatically deploy a topic.
- </para>
- <para>
- There are two overloaded versions of this operation.
- </para>
- <para>
- If the topic already exists but is undeployed it is deployed. Otherwise it is created and deployed.
- </para>
- <para>
- The name parameter represents the name of the destination to deploy.
- </para>
- <para>
- The jndiName parameter (optional) represents the full jndi name where to bind the destination. If this is not specified then the destination will be bound in <DefaultTopicJNDIContext>/<name>.
- </para>
- <para>
- The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the paging parameters mean.
- </para>
-
-</section>
-<section><title>UndeployTopic</title>
- <para>
- This operation lets you programmatically undeploy a topic.
- The queue is undeployed but is NOT removed from persistent storage.
- This operation returns true if the topic was successfully undeployed. otherwise it returns false.
- </para>
-</section>
-<section><title>DestroyTopic</title>
-<para>
- This operation lets you programmatically destroy a topic.
-</para>
-<para>
- The topic is undeployed and then all its data is destroyed from the database.
-</para>
-<warning><title>Warning</title>
- <para>
- Be careful when using this method since it will delete all data for the topic.
- </para>
-</warning>
- <para>This operation returns true if the topic was successfully destroyed. otherwise it returns false.
- </para>
- </section>
-<section><title>ListMessageCountersAsHTML</title>
- <para>
- This operation returns message counters in an easy to display HTML format.
- </para>
-</section>
-<section><title>ResetAllMesageCounters</title>
- <para>
- This operation resets all message counters to zero.
- </para>
-</section>
-<section><title>EnableMessageCounters</title>
- <para>
- This operation enables all message counters for all destinations. Message counters are disabled by default.
- </para>
-</section>
-<section><title>DisableMessageCounters</title>
- <para>
- This operation disables all message counters for all destinations. Message counters are disabled by default.
- </para>
-</section>
-<section><title>RetrievePreparedTransactions</title>
- <para>
- Retrieves a list of the Xids for all transactions currently in a prepared state on the node.
- </para>
-</section>
-<section><title>ShowPreparedTransactionsAsHTML</title>
- <para>
- Retrieves a list of the Xids for all transactions currently in a prepared state on the node in an easy to display HTML format.
- </para>
-</section>
-
-
-</section>
-
-
-
-
-
-
-
-
-
+ <para>
+ The most current information about using JBoss Messaging is always available from the relevant <citetitle>JBoss Messaging User Guide</citetitle> at <ulink url="http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/">http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/</ulink>.
+ </para>
</chapter>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2009-12-14 23:53:44 UTC (rev 97816)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2009-12-14 23:59:45 UTC (rev 97817)
@@ -99,7 +99,7 @@
Most modern operating systems now ship with performance tuning or profiling tools that can help you monitor CPU, memory, hard disk and network usage in real-time.
</para>
<para>
- On Windows the task manager and performance monitor can be helpful in identifying system performance bottlenecks while in unix based operating systems <literal>top</literal> and <literal>ps</literal> are used for the same purpose. Linux distributions such as Red Hat Enterprise Linux and Fedora provide a graphical user interface <literal>System Monitor</literal> that is useful to monitor system performance.
+ On Windows the task manager and performance monitor can be helpful in identifying system performance bottlenecks while in Unix based operating systems <literal>top</literal> and <literal>ps</literal> are used for the same purpose. Linux distributions such as Red Hat Enterprise Linux and Fedora provide a graphical user interface <literal>System Monitor</literal> that is useful to monitor system performance.
</para>
<para>
Operating system performance tuning is about resource management to respond to individual requests. Managing operating system scalability on the other hand involves managing resource consumption with varying volumes (low to very high) of requests.
@@ -134,7 +134,7 @@
<section id="JVM_Tuning">
<title>Tuning the JVM</title>
<para>
- For java based applications, it is recommended to also be familiar with tuning of your Java Virtual Machine (JVM). Some key aspects of your JVM that need tweaking include managing out of memory exceptions, java heap settings and garbage collection. Please refer to the JDK 6 documentation on <ulink url="http://java.sun.com/j2se/1.6.0/docs/">http://java.sun.com/j2se/1.6.0/docs/</ulink> for further discussions on this.
+ For Java-based applications, it is recommended to also be familiar with tuning of your Java Virtual Machine (JVM). Some key aspects of your JVM that need tweaking include managing out of memory exceptions, Java heap settings and garbage collection. Please refer to the JDK 6 documentation on <ulink url="http://java.sun.com/j2se/1.6.0/docs/">http://java.sun.com/j2se/1.6.0/docs/</ulink> for further discussions on this.
</para>
@@ -147,10 +147,10 @@
Good application design and development practices are critical to ensuring satisfactory application performance. Data reads or writes and processing by your applications may cause performance bottlenecks due to factors such as timeouts on remote servers memory allocation or network issues among other factors. Understanding how each application works is therefore crucial in identifying performance bottlenecks. Setting expected time duration each code part is expected to take can help develop realistic benchmarks against which the applications can be reviewed. These benchmarks should take into account high and low peak usage times for the applications and not averages as these may highly vary from the peak times.
</para>
<para>
- In addition, using bench-marking tools to test your applications may be a quick way to pinpoint issues in your code which can often be causes for performance bottlenecks. Iterative tests are recommended to identify cache and other hardware issues that may arise due to start up or other factors.
+ In addition, using bench`marking tools to test your applications may be a quick way to pinpoint issues in your code which can often be causes for performance bottlenecks. Iterative tests are recommended to identify cache and other hardware issues that may arise due to start up or other factors.
</para>
<para>
- The JBoss Enterprise Application Platform web console <ulink url="http://localhost:8080/web-console/">http://localhost:8080/web-console/</ulink> provides you with monitoring tools starting with the JVM Hardware environment statistics on the default page and access to monitoring tools and snapshots.
+ The JBoss Enterprise Application Platform web console <ulink url="http://localhost:8080/web-console/">http://localhost:8080/web-console/</ulink> provides you with monitoring tools starting with the JVM environment statistics on the default page and access to monitoring tools and snapshots.
</para>
<note><title>Performance Monitor v/s Profiler</title>
@@ -172,7 +172,7 @@
Instrumentation in the past would have had to be embedded in the application. Today, there are many solutions for instrumentation that do not require developers to code. Commercial products, and the JBoss AOP framework can be used for just this purpose. You can also turn on call statistics in the containers, and Hibernate statistics. For more on this please refer to the AOP and Hibernate project pages.
</para>
<para>
- Taking successive thread dumps (includes the current call stack for each Java Enterprise Application Platform thread) can give the application developers enough information to get a sense for what is going on in the application. This is something that you might do after the application has hit a performance wall. If the performance problem lasts for five minutes, you might generate a thread dump one a minute. You can use the JVM "jps -l" command to get a list of running Java applications and the process ids for each. Note the process id for the "org.jboss.Main" application. You will then run the "jstack ProcessID" command (replacing ProcessID with the "org.jboss.Main" process id) and that will generate the thread dump. Of course, you should redirect the output of the jstack command to save the output ("jstack ProcessID > threaddump1.txt").
+ Taking successive thread dumps (includes the current call stack for each Java Enterprise Application Platform thread) can give the application developers enough information to get a sense for what is going on in the application. This is something that you might do after the application has hit a performance wall. If the performance problem lasts for five minutes, you might generate a thread dump one a minute. You can use the JVM "jps -l" command to get a list of running Java applications and the process ids for each. Note the process ID for the "org.jboss.Main" application. You will then run the "jstack ProcessID" command (replacing ProcessID with the "org.jboss.Main" process ID) and that will generate the thread dump. Of course, you should redirect the output of the jstack command to save the output ("jstack ProcessID > threaddump1.txt").
</para>
@@ -195,21 +195,21 @@
</para>
<para>
- Running out of memory generates an Error that is not likely to be masked in a Java catch block because it is an Error rather than an Exception. An OOME is also thrown when the permanent memory is exhausted and that is not part of the heap per se. That is a JVM specific area of memory where information on loaded classes is maintained. If you have a mountain of classes (e.g, a lot of EJBs and JSP pages) you can easily exhaust this area. Oftentimes an application will fail to deploy or fail to redeploy. Increase your permanent memory space as follows to avoid OOMEs. The default with the <literal>-server</literal> switch is 64 megabytes:
-<screen>-XX:MaxPermSize?=256m</screen>
+ Running out of memory generates an Error that is not likely to be masked in a Java catch block because it is an Error rather than an Exception. An OOME is also thrown when the permanent memory is exhausted and that is not part of the heap. That is a JVM specific area of memory where information on loaded classes is maintained. If you have a mountain of classes (e.g, a lot of EJBs and JSP pages) you can easily exhaust this area. Oftentimes an application will fail to deploy or fail to redeploy. Increase your permanent memory space as follows to avoid OOMEs. The default with the <literal>-server</literal> switch is 64 megabytes:
+<screen>-XX:MaxPermSize=256m</screen>
</para>
<para>
Note this is in addition to the heap. In this case we have 512M heap, 256M permanent space for a total of 768 megabytes. Don't forget the JVM itself takes up a chunk of system memory and there is also per thread stack space (size varies based on OS). That can add up with a lot of HTTP/S processors.
</para>
<para>
- <literal>-XX:MaxPermSize?=256m -Xmx512m</literal> (total of 768 megabytes allocated from system - this is not the total size of the VM and does not include the space the VM allocates for the "C heap" or stack space)
+ <literal>-XX:MaxPermSize=256m -Xmx512m</literal> (total of 768 megabytes allocated from system - this is not the total size of the VM and does not include the space the VM allocates for the "C heap" or stack space)
</para>
<para>
The HotSpot Java Virtual Machine consists of various garbage collection tools which you can use to collect garbage collection information that you can use to tune your applications. You can find more information on the HotSpot Virtual machine on <ulink url="http://java.sun.com/javase/technologies/hotspot/">http://java.sun.com/javase/technologies/hotspot/</ulink>.
</para>
<para>
- Java 6 includes new tools that help monitor Java applications. Jmap can generate a heap dump file (<ulink url="http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html">http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html</ulink>) that can easily be read by the Eclipse Memory Analyzer tool (<ulink url="http://www.eclipse.org/mat/">http://www.eclipse.org/mat/</ulink>). The jstat tool (http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html) can help give you a precise picture of
+ Java 6 includes new tools that help monitor Java applications. Jmap can generate a heap dump file (<ulink url="http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html">http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html</ulink>) that can easily be read by the Eclipse Memory Analyzer tool (<ulink url="http://www.eclipse.org/mat/">http://www.eclipse.org/mat/</ulink>). The jstat tool (<ulink url="http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html">http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html</ulink>) can help give you a precise picture of
your permanent memory space and the other segments on the Java memory heap.
</para>
@@ -217,7 +217,7 @@
<section id="VFS_Tuning">
<title>VFS Tuning</title>
<para>
-When looking for various tuning options, most of the information that exists can be found in <classname>VFSUtils</classname> class.
+When looking for various tuning options for the VFS (Virtual File System), most of the information that exists can be found in <classname>VFSUtils</classname> class.
Its string constants point us to different possible system property settings we can use to configure VFS behavior:</para>
<itemizedlist>
@@ -403,7 +403,7 @@
<section id="Database_Tuning">
<title>Database Connection</title>
<para>
- Database performance tuning involves changing the initial database conceptual schema to improve performance. Irrespective of type, overall database management system performance tuning involves effective and efficient use of your hardware (Hard disk, CPU and RAM) and improving database read's and writes.
+ Database performance tuning involves changing the initial database conceptual schema to improve performance. Irrespective of type, overall database management system performance tuning involves effective and efficient use of your hardware (hard disk, CPU and RAM) and improving database reads and writes.
</para>
<para>
Resource limits set by your operating system may also set limits on your database management system. A database administrator can analyze a database and identify performance bottlenecks through taking the above factors into consideration and adjusting the necessary database management system parameters such as writing dirty buffers to disk, checkpoints and log file rotations. In some instances hardware upgrades may also be necessary to improve database performance.
@@ -426,7 +426,7 @@
<note><title>Note</title>
<para>
- Please note that the name of the file must end with <filename>-ds.xml</filename> in order for the JBoss Enterprise Application Platform to recognize it as a <emphasis>data source file</emphasis>. The Postgres database data source file for example is named <filename>postgres-ds.xml</filename>.
+ Please note that the name of the file must end with <filename>-ds.xml</filename> in order for the JBoss Enterprise Application Platform to recognize it as a <emphasis>data source file</emphasis>. The PostgreSQL database data source file for example is named <filename>postgres-ds.xml</filename>.
</para>
</note>
@@ -438,7 +438,7 @@
<section id="Clustering_Tuning">
<title>Clustering Tuning</title>
- <para>If you are running your application in a cluster, particularly if if it involves high volume state replication around the cluster, there are a number of possible performance optimizations.
+ <para>If you are running your application in a cluster, particularly if it involves high volume state replication around the cluster, there are a number of possible performance optimizations.
As with any performance optimizations, always load test your application before and after making changes to verify the change has the intended effect, and make one change at a time so it's
clear what change has what effect.</para>
@@ -478,7 +478,7 @@
<section>
<title>JGroups Message Bundling</title>
<para>The JGroups group communication library used by the Enterprise Application Platform provides a feature known as "message bundling". Message
- bundling is similar to nagling on a TCP socket -- small messages are queued before sending (for up to a configurable maximum time) until a configurable number
+ bundling is similar to nagling on a TCP socket — small messages are queued before sending (for up to a configurable maximum time) until a configurable number
of bytes have accumulated, and then the queued messages are bundled and sent as one large message. Use of bundling can have significant performance benefits
for high-volume asynchronous session replication. However, it is not enabled by default, as bundling can add significant latency to other types of intra-cluster
traffic, particularly clustered Hibernate/JPA Second Level Cache traffic.</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2009-12-14 23:53:44 UTC (rev 97816)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2009-12-14 23:59:45 UTC (rev 97817)
@@ -105,14 +105,9 @@
</listitem>
</itemizedlist>
- <para>The InvokerLocator is derived from this file. <emphasis
- role="bold">The important fact to note is that the attribute "isParam"
- determines if a parameter is to be included in the
- InvokerLocator.</emphasis> If "isParam" is omitted (or if it is set to
- "false"), then the parameter applies only to the server and is not
- communicated to the client. It follows that the InvokerLocator for this
- Remoting server is (assuming the value of ${jboss.bind.address} is
- bluemonkeydiamond.com)</para>
+ <para>
+ The InvokerLocator is derived from this file. <emphasis role="bold">The important fact to note is that the attribute "isParam" determines if a parameter is to be included in the InvokerLocator.</emphasis> If "isParam" is omitted or set to false, the parameter will apply only to the server. In this case, the parameter will not be transmitted to the client. The InvokerLocator for a Remoting server with a ${jboss.bind.address} of bluemonkeydiamond.com would be:
+ </para>
<programlisting>
bisocket://bluemonkeydiamond.com:4457/?marshaller=
@@ -187,9 +182,8 @@
<para>In this version, the configuration information is expressed in the
HornetQConfiguration <classname>ServerConfiguration</classname> POJO, which
is then injected into the HornetQConnector
- <classname>org.jboss.remoting.transport.Connector</classname> POJO. The
- syntax is that of the Microcontainer, which is beyond the scope of this
- chapter. One variation from the MBean version is the use of the
+ <classname>org.jboss.remoting.transport.Connector</classname> POJO.
+ The syntax is that of the Microcontainer, which is beyond the scope of this chapter. See <xref linkend="microcontainer"/> for details. One variation from the MBean version is the use of the
ServiceBindingManager, which is also beyond the scope of this chapter. Note
that the @org.jboss.aop.microcontainer.aspects.jmx.JMX annotation causes the
HornetQConnector to be visible as an MBean named
Modified: projects/docs/enterprise/5.0/Installation_Guide/en-US/Introduction.xml
===================================================================
--- projects/docs/enterprise/5.0/Installation_Guide/en-US/Introduction.xml 2009-12-14 23:53:44 UTC (rev 97816)
+++ projects/docs/enterprise/5.0/Installation_Guide/en-US/Introduction.xml 2009-12-14 23:59:45 UTC (rev 97817)
@@ -37,7 +37,7 @@
<section id="introduction-Feedback">
<title>Feedback</title>
<para>
- If you spot a typo in this guide, or if you have thought of a way to make this manual better, we would love to hear from you! Submit a report in <ulink url="http://jira.jboss.com/jira/browse/JBPAPP">JIRA</ulink> against the Product: JBoss Enterprise Application Platform, Version: <replaceable><version></replaceable>, Component: <emphasis>Doc</emphasis>. If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, include the section number and some of the surrounding text so we can find it easily.
+ If you spot a typo in this guide, or if you have thought of a way to make this manual better, we would love to hear from you! Submit a report in <ulink url="http://jira.jboss.com/jira/browse/JBPAPP">JIRA</ulink> against the Product: JBoss Enterprise Application Platform, Version: <replaceable>5.0.0</replaceable>, Component: <emphasis>Documentation</emphasis>. If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, include the section number and some of the surrounding text so we can find it easily.
</para>
</section>
More information about the jboss-cvs-commits
mailing list