[jboss-cvs] JBossAS SVN: r93194 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Sep 3 19:40:06 EDT 2009
Author: irooskov at redhat.com
Date: 2009-09-03 19:40:05 -0400 (Thu, 03 Sep 2009)
New Revision: 93194
Modified:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.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/Administration_And_Configuration_Guide/en-US/Transactions.xml
Log:
updated with correct removal of AS references
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -8,7 +8,7 @@
<title>How to Use Alternative Databases</title>
<para>
<indexterm><primary>Configuration</primary><secondary>databases</secondary></indexterm>
-JBoss utilizes the Hypersonic database as its default database. While this is good for development and prototyping, you or your company will probably require another database to be used for production. This chapter covers configuring JBoss Enterprise Application Platform to use alternative databases. We cover the procedures for all officially supported databases on the JBoss Application Server. They include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, Sybase ASE 12.5, as well as MS SQL 2005.
+JBoss utilizes the Hypersonic database as its default database. While this is good for development and prototyping, you or your company will probably require another database to be used for production. This chapter covers configuring JBoss Enterprise Application Platform to use alternative databases. We cover the procedures for all officially supported databases on the JBoss Enterprise Application Platform. They include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, Sybase ASE 12.5, as well as MS SQL 2005.
</para>
<para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss Enterprise Application Platform. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss Enterprise Application Platform, you can still use any backend database by setting up the appropriate data source connection. </para>
@@ -20,7 +20,7 @@
<section>
<title>Install JDBC Drivers</title>
- <para>For the JBoss Application Server and our applications to use the external database, we also need to install the database's JDBC driver. The JDBC driver is a JAR file, which you'll need to copy into your JBoss Enterprise Application Platform's <literal><JBoss_Home>/server/all/lib</literal> directory. Replace <literal>all</literal> with the server configuration you are using if needed. This file is loaded when JBoss starts up. So if you have the JBoss Enterprise Application Platform running, you'll need to shut down and restart. The availability of JDBC drivers for different databases are as follows.
+ <para>For the JBoss Enterprise Application Platform and our applications to use the external database, we also need to install the database's JDBC driver. The JDBC driver is a JAR file, which you'll need to copy into your JBoss Enterprise Application Platform's <literal><JBoss_Home>/server/all/lib</literal> directory. Replace <literal>all</literal> with the server configuration you are using if needed. This file is loaded when JBoss starts up. So if you have the JBoss Enterprise Application Platform running, you'll need to shut down and restart. The availability of JDBC drivers for different databases are as follows.
</para>
@@ -644,7 +644,7 @@
<section>
<title>Support Foreign Keys in CMP Services</title>
- <para>Next, we need to go change the <literal><JBoss_Home>/server/all/conf/standardjbosscmp-jdbc.xml</literal> file so that the <literal>fk-constraint</literal> property is <literal>true</literal>. That is needed for all external databases we support on the JBoss Application Server. This file configures the database connection settings for the EJB2 CMP beans deployed in the JBoss Enterprise Application Platform.</para>
+ <para>Next, we need to go change the <literal><JBoss_Home>/server/all/conf/standardjbosscmp-jdbc.xml</literal> file so that the <literal>fk-constraint</literal> property is <literal>true</literal>. That is needed for all external databases we support on the JBoss Enterprise Application Platform. This file configures the database connection settings for the EJB2 CMP beans deployed in the JBoss Enterprise Application Platform.</para>
<programlisting role="XML"><fk-constraint>true</fk-constraint></programlisting>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Cache.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -7,7 +7,7 @@
<section><title>What is JBoss Cache?</title>
<para>
<indexterm><primary>JBoss Cache</primary><secondary>about</secondary></indexterm>
- JBoss Cache is a tree-structured, clustered, transactional cache. It is the backbone for many fundamental JBoss Application Server clustering services, including - in certain versions - clustering JNDI, HTTP and EJB sessions. </para>
+ JBoss Cache is a tree-structured, clustered, transactional cache. It is the backbone for many fundamental JBoss Enterprise Application Platform clustering services, including - in certain versions - clustering JNDI, HTTP and EJB sessions. </para>
<para>JBoss Cache can also be used as a standalone transactional and clustered caching library or even an object oriented data store. It can even be embedded in other enterprise Java frameworks and application servers such as BEA WebLogic or IBM WebSphere, Tomcat, Spring, Hibernate, and many others. It is also very commonly used directly by standalone Java applications that do not run from within an application server, to maintain clustered state. </para>
</section>
@@ -71,13 +71,13 @@
JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found on <xref linkend="jgroups"/>
</para>
- <!--<para>The following is the JBoss Cache JGroups and JBoss Application Server compatibility matrix.</para>
+ <!--<para>The following is the JBoss Cache JGroups and JBoss Enterprise Application Platform compatibility matrix.</para>
<para>
- <table frame="all"><title>JBoss Application Server + JBoss Cache</title>
+ <table frame="all"><title>JBoss Enterprise Application Platform + JBoss Cache</title>
<tgroup cols="3"><tbody>
<row>
<entry>
- <para>JBoss Application Server </para>
+ <para>JBoss Enterprise Application Platform </para>
</entry>
<entry>
<para>Ships with JBoss Cache </para>
@@ -206,11 +206,11 @@
<para>
<!--
- <table frame="all"><title>JBoss Application Server + Jgroups compatibility matrix</title>
+ <table frame="all"><title>JBoss Enterprise Application Platform + Jgroups compatibility matrix</title>
<tgroup cols="3"><tbody>
<row>
<entry>
- <para>JBoss Application Server </para>
+ <para>JBoss Enterprise Application Platform </para>
</entry>
<entry>
<para>Ships with JGroups </para>
@@ -584,11 +584,11 @@
</table>-->
</para>
- <para>In the JBoss Application Server 5, JBoss cache runs in the <emphasis>all</emphasis> configuration of the application server(i.e <JBOSS_HOME>/server/all). All you need to do is start the server with this configuration.
+<para>In the JBoss Enterprise Application Platform 5, JBoss cache runs in the <emphasis>all</emphasis> configuration of the Enterprise Application Platform (for instance, <JBOSS_HOME>/server/all). All you need to do is start the server with this configuration.
<screen><command><JBOSS_HOME>/bin/./run.sh -c all</command></screen>
All required jars will be on the classpath. Otherwise, you will need to ensure jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like <filename>JdbmCacheLoader</filename>. The simplest way to do this is to copy the jars from the JBoss Cache distribution's <filename>lib</filename> directory to the server configurations <emphasis>all</emphasis> <filename>lib</filename> directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR. </para>
- <para>It is possible to deploy a JBoss Cache 2.0 instance in JBoss Enterprise Application Platform 4.x (at least in 4.2.0.GA; other AS releases are completely untested). However, the significant API changes between the JBoss Cache 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on JBoss Cache will work with JBoss Cache 2.x. Also, be aware that usage of JBoss Cache 2.x in AS 4.x is not something the JBoss Cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.) </para>
+ <!--<para>It is possible to deploy a JBoss Cache 2.0 instance in JBoss Enterprise Application Platform 4.x (at least in 4.2.0.GA; other AS releases are completely untested). However, the significant API changes between the JBoss Cache 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on JBoss Cache will work with JBoss Cache 2.x. Also, be aware that usage of JBoss Cache 2.x in AS 4.x is not something the JBoss Cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.) </para>-->
<para>Note in the <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file">http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file</ulink> the value of the mbean element's code attribute: org.jboss.cache.jmx.CacheJmxWrapper . This is the class JBoss Cache uses to handle JMX integration; the Cache itself does not expose an MBean interface. See the <ulink url="http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#jmx.mbeans">JBoss Cache MBeans section</ulink> for more on the CacheJmxWrapper . </para>
<para>Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache: </para>
<para>
@@ -621,15 +621,15 @@
</section>
<section><title>JMX-Based Deployment in JBoss Enterprise Application Platform (JBoss Enterprise Application Platform 5.x and 4.x)</title>
<para>
- If PojoCache is run in JBoss Enterprise Application Platform then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss Enterprise Application Platform MBean deployment descriptor, so the AS's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
+ If PojoCache is run in JBoss Enterprise Application Platform then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss Enterprise Application Platform MBean deployment descriptor, so the Enterprise Application Platform's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
</para>
<para>
- In AS 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR.
+ In Enterprise Application Platform 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR.
</para>
+ <!-- <para>
+ It is possible, to deploy a POJO Cache 2.0 instance in JBoss Enterprise Application Platform 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard Enterprise Application Platform 4.x clustering services (for example, http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in Enterprise Application Platform 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
+ </para> -->
<para>
- It is possible, to deploy a POJO Cache 2.0 instance in JBoss Enterprise Application Platform 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in AS 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
- </para>
- <para>
Note in the example the value of the mbean element's code attribute: org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper. This is the class JBoss Cache uses to handle JMX integration; the PojoCache itself does not expose an MBean interface. See the JBoss Cache MBeans section for more on the PojoCacheJmxWrapper.
</para>
<para>
@@ -656,7 +656,7 @@
</section>
<section><title>Via JBoss Microcontainer (JBoss Enterprise Application Platform 5.x)</title>
<para>
- Beginning with AS 5, JBoss Enterprise Application Platform also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.
+ Beginning with Enterprise Application Platform 5, JBoss Enterprise Application Platform also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.
</para>
<para>
Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss Enterprise Application Platform. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service.
@@ -665,7 +665,7 @@
The rules for how to deploy the file, how to package it, how to ensure the required jars are on the classpath, etc. are the same as for a JMX-based deployment.
</para>
<para>
- Following is an abbreviated example -beans.xml file. The details of building up the Configuration are omitted; see the "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for a more complete example. If you look in the <filename>server/all/deploy</filename> directory of an AS 5 installation, you can find several more examples.
+ Following is an abbreviated example -beans.xml file. The details of building up the Configuration are omitted; see the "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for a more complete example. If you look in the <filename>server/all/deploy</filename> directory of an Enterprise Application Platform 5 installation, you can find several more examples.
</para>
<programlisting role="XML"><?xml version="1.0" encoding="UTF-8"?>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -413,7 +413,7 @@
<para>Aliases can be configured by editing the "CacheManager"
bean in the <literal>jboss-cache-manager-jboss-beans.xml</literal>
file. The following redacted config shows the standard aliases in
- Enterprise Application Server 5.0.0:</para>
+ Enterprise Application Platform 5:</para>
<programlisting><![CDATA[
<bean name="CacheManager" class="org.jboss.ha.cachemanager.CacheManager">
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -44,7 +44,7 @@
server instances divided into three sets, with the third set only
having one node. This sort of topology can be set up simply by configuring
the Enterprise Application Platform instances such that within a set of nodes meant to form a cluster the
- Channel configurations and names match while they differ from any other channel configurations and names match while they differ from any other channels on the same network. The Enterprise Application Platform tries to make this is easy as possible, such that servers that are meant to cluster only need to have the same values passed on the command line to the <literal>-g</literal> (partition name) and <literal>-u</literal> (multicast address) startup switches. For each set of servers, different values should be chosen. The sections on “JGroups Configuration” and “Isolating JGroups Channels” cover in detail how to configure the AS such that desired peers find each other and unwanted peers do not.</para>
+ Channel configurations and names match while they differ from any other channel configurations and names match while they differ from any other channels on the same network. The Enterprise Application Platform tries to make this is easy as possible, such that servers that are meant to cluster only need to have the same values passed on the command line to the <literal>-g</literal> (partition name) and <literal>-u</literal> (multicast address) startup switches. For each set of servers, different values should be chosen. The sections on “JGroups Configuration” and “Isolating JGroups Channels” cover in detail how to configure the Enterprise Application Platform such that desired peers find each other and unwanted peers do not.</para>
<figure id="clustering-Partition.fig">
<title>Clusters and server nodes</title>
<mediaobject>
@@ -68,9 +68,9 @@
<section id="clustering-concepts-arch-proxy">
<title>Client-side interceptor architecture</title>
<para>
- Most remote services provided by the JBoss application server, including
+ Most remote services provided by the JBoss Enterprise Application Platform, including
JNDI, EJB, JMS, RMI and JBoss Remoting, require the client to obtain
- (e.g., to look up and download) a remote proxy object. The proxy object
+ (for example, to look up and download) a remote proxy object. The proxy object
is generated by the server and it implements the business interface of
the service. The client then makes local method calls against the proxy
object. The proxy automatically routes the call across the network where
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -223,9 +223,9 @@
is in another VM.</para>
- <section><title>For clients running inside the application server</title>
+ <section><title>For clients running inside the Enterprise Application Platform</title>
<para>
- If you want to access HA-JNDI from inside the application server, you
+ If you want to access HA-JNDI from inside the Enterprise Application Platform, you
must explicitly configure your <literal>InitialContext</literal> by
passing in JNDI properties to the constructor. The following code shows
how to create a naming Context bound to HA-JNDI:
@@ -274,7 +274,7 @@
Do not attempt to simplify things by placing a <literal>jndi.properties</literal>
file in your deployment or by editing the Enterprise Application Platform's <literal>conf/jndi.properties</literal>
file. Doing either will almost certainly break things for your application
- and quite possibly across the application server. If you want to externalize
+ and quite possibly across the server. If you want to externalize
your client configuration, one approach is to deploy a properties file not
named <literal>jndi.properties</literal>, and then programatically create a
<literal>Properties</literal> object that loads that file's contents.
@@ -336,11 +336,11 @@
<section><title>Why do this programmatically and not just put this in a jndi.properties file?</title>
<para>
- The JBoss application server's internal naming environment is controlled by the <filename>conf/jndi.properties</filename> file, which should not be edited.
+ The JBoss Enterprise Application Platform's internal naming environment is controlled by the <filename>conf/jndi.properties</filename> file, which should not be edited.
</para>
<para>
- No other jndi.properties file should be deployed inside the application server because of the possibility of its being found on the classpath when it shouldn't and thus disrupting the internal operation of the server. For example, if an EJB deployment included a jndi.properties configured for HA-JNDI, when the server binds the EJB proxies into JNDI it will likely bind them into the replicated HA-JNDI tree and not into the local JNDI tree where they belong.
+ No other jndi.properties file should be deployed inside the Enterprise Application Platform because of the possibility of its being found on the classpath when it shouldn't and thus disrupting the internal operation of the server. For example, if an EJB deployment included a jndi.properties configured for HA-JNDI, when the server binds the EJB proxies into JNDI it will likely bind them into the replicated HA-JNDI tree and not into the local JNDI tree where they belong.
</para>
</section>
@@ -353,7 +353,7 @@
</section>
-<section><title>For clients running outside the application server</title>
+<section><title>For clients running outside the Enterprise Application Platform</title>
<para>The JNDI client needs to be aware of the HA-JNDI cluster. You can
pass a list of JNDI servers (i.e., the nodes in the HA-JNDI cluster) to the
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/JGroups.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -6,7 +6,7 @@
<para>
<indexterm><primary>JGroups</primary><secondary>multicast communication toolkit</secondary></indexterm>
- JBoss AS clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Application Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
+ JBoss Enterprise Application Platform clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Application Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
</para>
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-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -10,8 +10,8 @@
<indexterm><primary>JBoss Enterprise Application Platform 5 Performance Tuning</primary><secondary>performance</secondary></indexterm>
<indexterm><primary>Performance</primary><secondary>JBoss Enterprise Application Platform 5 Performance Tuning</secondary></indexterm>
<indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>performance tuning</secondary></indexterm>
- Developing applications and deploying them to an application server does not guarantee best performance without performance tuning of the applications and server.
- Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and application server.
+ Developing applications and deploying them to an Enterprise Application Platform does not guarantee best performance without performance tuning of the applications and server.
+ Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and Enterprise Application Platform.
</para>
<para>
Application design, hardware/network profile, operating system, application software development, testing and deployment all play a major role in performance tuning. A bottleneck in performance therefore could be caused by these factors not just your application. Recent studies show that most performance problems are the result of the applications not the middleware or the operating systems. This could be associated with the technological developments in computer software, hardware and networking which has increased their reliability.
@@ -150,7 +150,7 @@
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 Application Server 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 Hardware 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 application server 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>
@@ -181,9 +181,9 @@
<section id="JBAS_Tuning">
- <title>Tuning JBoss Application Server</title>
+ <title>Tuning JBoss Enterprise Application Platform</title>
<para>
- Before tuning the JBoss Enterprise Application Platform, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the application server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the application server. This section discusses these among other JBoss Application Server performance tuning topics.
+ Before tuning the JBoss Enterprise Application Platform, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the server. This section discusses these among other JBoss Enterprise Application Platform performance tuning topics.
</para>
<section id="Memory_Usage_Tuning"><title>Memory usage</title>
@@ -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 application server 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 Postgres database data source file for example is named <filename>postgres-ds.xml</filename>.
</para>
</note>
@@ -439,7 +439,7 @@
<section id="Other_Tuning">
<title>Other key configurations</title>
<para>
- Other key configurations required for performance tuning of your application server include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool.
+ Other key configurations required for performance tuning of your Enterprise Application Platform include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool.
</para>
<para>
JBoss Enterprise Application Platform 5 has a robust thread pooling, that should be sized appropriately.
@@ -448,7 +448,7 @@
</para>
<para>
- The new administration console can be used for configuring and managing different aspects of the application server environment.
+ The new administration console can be used for configuring and managing different aspects of the Enterprise Application Platform environment.
</para>
<para>
The <literal>default</literal> configuration is appropriate for development, but not necessarily for a production environment. In the default configuration, console logging is enabled. Console logging is ideal for development, especially within the IDE, as you get all the log messages to show in the IDE console view.
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-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Remoting.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -24,7 +24,7 @@
invocations collocated in a single JVM, and implements multihomed
servers.</para>
- <para>In the Application Server, Remoting supplies the transport layer for the
+ <para>In the Enterprise Application Platform, Remoting supplies the transport layer for the
EJB2, EJB3, and Messaging subsystems. In each case, the configuration of
Remoting is largely predetermined and fixed, but there are times when it is
useful to know how to alter a Remoting configuration. </para>
@@ -44,7 +44,7 @@
to use a socket timeout of 10000 and to use JBoss Serialization. A Remoting
client can use an InvokerLocator to connect to a given server. </para>
- <para>In the Application Server, Remoting servers and clients are created far
+<para>In the Enterprise Application Platform, Remoting servers and clients are created far
below the surface and are accessible only through configuration files.
Moreover, when a SLSB, for example, is downloaded from the JNDI directory, it
comes with a copy of the InvokerLocator, so that it knows how to contact the
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2009-09-03 22:27:07 UTC (rev 93193)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2009-09-03 23:40:05 UTC (rev 93194)
@@ -4,7 +4,7 @@
<title>Transaction Management</title>
<section>
<title>Overview</title>
- <para>Transaction support in JBoss EAP is provided by JBossTS, a mature, modular,
+ <para>Transaction support in JBoss Enterprise Application Platform is provided by JBossTS, a mature, modular,
standards based, highly configurable transaction manager. By default the
server runs with the local-only JTA module of JBossTS installed. This module
provides an implementation of the standard JTA API for use by other internal
@@ -12,7 +12,7 @@
code. It is suitable for coordinating ACID transactions that involve one or
more XA Resource managers, such as databases or message queues.</para>
<para>Two additional, optional, JBossTS transaction modules are also shipped with
- JBossEAP and may be deployed to provide additional functionality if
+ JBoss Enterprise Application Platform and may be deployed to provide additional functionality if
required. These are:</para>
<itemizedlist>
<listitem>
@@ -47,7 +47,7 @@
accessed internally by the local WS-AT and WS-BA
implementations. However, this WS-C service can also be used
to provide remote coordination for WS-AT and WS-BA
- transactions created in other JBoss AS instances or
+ transactions created in other JBoss server instances or
non-JBoss containers.</para>
</listitem>
</itemizedlist>
@@ -216,7 +216,7 @@
implementations, which are provided by the various resource managers. In
most instances, resource managers will be databases, message queues or 3rd
party JCA resource adapters. The list of JDBC database drivers and servers
- certified for use with JBoss EAP can be found on the redhat.com website. In
+ certified for use with JBoss Enterprise Application Platform can be found on the redhat.com website. In
addition there is a reasonable probability of any driver that complies with
the relevant standards functioning correctly. However, interpretation of the
XA specification does differ from one vendor to another, as does quality of
@@ -473,11 +473,11 @@
<section>
<title>Experimental Components</title>
<para> In addition to the supported components of JBossTS that ship as part of JBoss
- EAP, there is ongoing feature work that may eventually find its way into
+ Enterprise Application Platform, there is ongoing feature work that may eventually find its way into
future releases of the product. Meanwhile these prototype components are
available via from the jboss.org community site. Users are cautioned that
there is no guarantee these will work correctly and nor are they covered by
- the EAP support agreement. However, some of the advanced functionality
+ the Enterprise Application Platform support agreement. However, some of the advanced functionality
available may nevertheless be attractive to projects in the early stages of
development. Users downloading these prototypes must be aware of the
limitations concerning module compatibility, in accordance with the 'source
@@ -525,17 +525,17 @@
functionality.</para>
<para> The source code for JBossTS can be downloaded direct from the project's svn
repository at http://anonsvn.jboss.org/repos/labs/labs/jbosstm/ To find the
- version matching the binaries in JBoss EAP, consult your server logs. At
+ version matching the binaries in JBoss Enterprise Application Platform, consult your server logs. At
startup the server prints a string similar to:</para>
<para>INFO [TransactionManagerService] JBossTS Transaction Service (JTA version -
tag:JBOSSTS_4_6_1_GA_CP02) - JBoss Inc.</para>
<para>The value given for the tag corresponds to a tree under /tags/ in the svn
repository. Note that the version refers to the JBossTS releases consumed by
- EAP, not the EAP release numbering. Users building the EAP from source may
+ Enterprise Application Platform, not the Enterprise Application Platform release numbering. Users building the Enterprise Application Platform from source may
also consult the version.jboss.jbossts value in
component-matix/pom.xml</para>
<para>Please note that installing any version of JBossTS other than those provided
- with the EAP distribution or its CP releases is not supported. Also note
+ with the Enterprise Application Platform distribution or its CP releases is not supported. Also note
that, whilst some JBossTS components are packaged individually, it is not
supported to mix and match versions. i.e. do not run the JTA from one tag
with the XTS from another. API and functionality changes between releases
More information about the jboss-cvs-commits
mailing list