[hornetq-commits] JBoss hornetq SVN: r9266 - trunk/docs/user-manual/en.
do-not-reply at jboss.org
do-not-reply at jboss.org
Wed May 26 07:50:27 EDT 2010
Author: gaohoward
Date: 2010-05-26 07:50:26 -0400 (Wed, 26 May 2010)
New Revision: 9266
Modified:
trunk/docs/user-manual/en/appserver-integration.xml
trunk/docs/user-manual/en/clusters.xml
trunk/docs/user-manual/en/configuration-index.xml
trunk/docs/user-manual/en/configuring-transports.xml
trunk/docs/user-manual/en/diverts.xml
trunk/docs/user-manual/en/examples.xml
trunk/docs/user-manual/en/ha.xml
trunk/docs/user-manual/en/interoperability.xml
trunk/docs/user-manual/en/large-messages.xml
trunk/docs/user-manual/en/management.xml
trunk/docs/user-manual/en/message-grouping.xml
trunk/docs/user-manual/en/messaging-concepts.xml
trunk/docs/user-manual/en/persistence.xml
trunk/docs/user-manual/en/pre-acknowledge.xml
trunk/docs/user-manual/en/security.xml
trunk/docs/user-manual/en/thread-pooling.xml
trunk/docs/user-manual/en/using-server.xml
Log:
typo
Modified: trunk/docs/user-manual/en/appserver-integration.xml
===================================================================
--- trunk/docs/user-manual/en/appserver-integration.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/appserver-integration.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -219,7 +219,7 @@
that the sending of the message will be done as part of the JTA transaction being used
by the component.</para>
<para>This means that if the sending of the message fails the overall transaction would
- rollback and the message be redelivered. Heres an example of this from within an
+ rollback and the message be re-sent. Heres an example of this from within an
MDB:</para>
<programlisting>@MessageDriven(name = "MDBMessageSendTxExample",
activationConfig =
@@ -459,7 +459,7 @@
<entry>
<link linkend="configuration.discovery-group.refresh-timeout">DiscoveryRefreshTimeout</link></entry>
<entry>Long</entry>
- <entry>The timeout, in milli seconds, to refresh.</entry>
+ <entry>The timeout, in milliseconds, to refresh.</entry>
</row>
<row>
<entry>
@@ -816,7 +816,7 @@
<config-property-value>host=127.0.0.1;port=5446</config-property-value>
</config-property>
</programlisting>
- <para>This configures the resource adapter to connect to a server running on localhosr listening on port 5446</para>
+ <para>This configures the resource adapter to connect to a server running on localhost listening on port 5446</para>
<para>You will also need to configure any outbound connections to also connect to this server. This can be done
by either configuring the jms-ds.xml file found under <literal>deploy/hornetq.sar</literal> or creating a
new configuration file and making sure the filename ends in -ds.xml</para>
@@ -873,7 +873,7 @@
(depending on the transaction outcome) when the server is restarted.</para>
<section>
<title>XA Recovery Configuration</title>
- <para>To enable HornetQs XA Recovery, the Recovery Manager must be configured to connect
+ <para>To enable HornetQ's XA Recovery, the Recovery Manager must be configured to connect
to HornetQ to recover its resources. The following property must be added to the
<literal>jta</literal> section of <literal>conf/jbossts-properties.xml</literal>
of JBoss AS profiles:</para>
Modified: trunk/docs/user-manual/en/clusters.xml
===================================================================
--- trunk/docs/user-manual/en/clusters.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/clusters.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -254,8 +254,8 @@
Connection jmsConnection2 = jmsConnectionFactory.createConnection();</programlisting></para>
<para>The <literal>refresh-timeout</literal> can be set directly on the connection
- factory by using the setter method <literal>setDiscoveryRefreshTimeout() if you
- want to change the default value.</literal></para>
+ factory by using the setter method <literal>setDiscoveryRefreshTimeout()</literal> if you
+ want to change the default value.</para>
<para>There is also a further parameter settable on the connection factory using the
setter method <literal>setDiscoveryInitialWaitTimeout()</literal>. If the connection
factory is used immediately after creation then it may not have had enough time
@@ -279,8 +279,8 @@
</programlisting></para>
<para>The <literal>refresh-timeout</literal> can be set directly on the session
- factory by using the setter method <literal>setDiscoveryRefreshTimeout() if you
- want to change the default value.</literal></para>
+ factory by using the setter method <literal>setDiscoveryRefreshTimeout()</literal> if you
+ want to change the default value.</para>
<para>There is also a further parameter settable on the session factory using the
setter method <literal>setDiscoveryInitialWaitTimeout()</literal>. If the session factory
is used immediately after creation then it may not have had enough time to
@@ -354,7 +354,7 @@
servers. By having multiple cluster connections on different addresses a
single HornetQ Server can effectively take part in multiple clusters
simultaneously.</para>
- <para>By careful not to have multiple cluster connections with overlapping
+ <para>Be careful not to have multiple cluster connections with overlapping
values of <literal>address</literal>, e.g. "europe" and "europe.news" since
this could result in the same messages being distributed between more than
one cluster connection, possibly resulting in duplicate deliveries. </para>
Modified: trunk/docs/user-manual/en/configuration-index.xml
===================================================================
--- trunk/docs/user-manual/en/configuration-index.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/configuration-index.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -903,7 +903,7 @@
<entry><link linkend="undelivered-messages.configuring"
>address-settings.dead-letter-address</link></entry>
<entry>String</entry>
- <entry>the address to send dead messages too</entry>
+ <entry>the address to send dead messages to</entry>
<entry/>
</row>
<row>
@@ -918,7 +918,7 @@
<entry><link linkend="message-expiry.configuring"
>address-settings.expiry-address</link></entry>
<entry>String</entry>
- <entry>the address to send expired messages too</entry>
+ <entry>the address to send expired messages to</entry>
<entry/>
</row>
<row>
@@ -1003,7 +1003,7 @@
<entry><link linkend="clusters.static.servers">connection-factory.connectors</link>
</entry>
<entry>String</entry>
- <entry>A list of connectors used bu the connection factory</entry>
+ <entry>A list of connectors used by the connection factory</entry>
<entry />
</row>
<row>
Modified: trunk/docs/user-manual/en/configuring-transports.xml
===================================================================
--- trunk/docs/user-manual/en/configuring-transports.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/configuring-transports.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -195,7 +195,7 @@
<itemizedlist>
<listitem>
<para><literal>use-nio</literal>. If this is <literal>true</literal> then Java
- non blocking NIO will be used. If set to <literal>false</literal> than old
+ non blocking NIO will be used. If set to <literal>false</literal> then old
blocking Java IO will be used.</para>
<para>If you require the server to handle many concurrent connections, we highly
recommend that you use non blocking Java NIO. Java NIO does not maintain a
@@ -274,7 +274,7 @@
switch required. If you want the lowest latency and the possible expense of
some reduction in throughput then you can make sure <literal
>direct-deliver</literal> to true. The default value for this parameter
- is <literal>true</literal>. If you are willingh to take some small extra hit
+ is <literal>true</literal>. If you are willing to take some small extra hit
on latency but want the highest throughput set this parameter to <literal
>false</literal>.</para>
</listitem>
@@ -438,7 +438,7 @@
<itemizedlist>
<listitem>
<para>endpoint - This is the name of the netty acceptor that the servlet will
- forward its packets too. You can see it matches the name of the <literal
+ forward its packets to. You can see it matches the name of the <literal
>host</literal> param.</para>
</listitem>
</itemizedlist>
Modified: trunk/docs/user-manual/en/diverts.xml
===================================================================
--- trunk/docs/user-manual/en/diverts.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/diverts.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -24,7 +24,7 @@
some simple server configuration.</para>
<para>Diverts allow you to transparently divert messages routed to one address to some other
address, without making any changes to any client application logic.</para>
- <para>Diverts can be <emphasis>exclusive</emphasis>, meaning that that the message is diverted
+ <para>Diverts can be <emphasis>exclusive</emphasis>, meaning that the message is diverted
to the new address, and does not go to the old address at all, or they can be
<emphasis>non-exclusive</emphasis> which means the message continues to go the old
address, and a <emphasis>copy</emphasis> of it is also sent to the new address.
@@ -92,7 +92,7 @@
the new address. The original message continues to the old address</para>
<para>You can therefore think of non-exclusive diverts as <emphasis>splitting</emphasis> a
message flow.</para>
- <para>Non exclusive diverts can be configured in the same was as exclusive diverts with an
+ <para>Non exclusive diverts can be configured in the same way as exclusive diverts with an
optional filter and transformer, here's an example non-exclusive divert, again from the
divert example:</para>
<programlisting>
Modified: trunk/docs/user-manual/en/examples.xml
===================================================================
--- trunk/docs/user-manual/en/examples.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/examples.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -458,7 +458,7 @@
</section>
<section>
<title>Topic Selector 2</title>
- <para>The <literal>topic-selector-example1</literal> example shows you how to
+ <para>The <literal>topic-selector-example2</literal> example shows you how to
selectively consume messages using message selectors with topic consumers.</para>
</section>
<section id="examples.transaction-failover">
@@ -513,7 +513,7 @@
<section>
<title>Java EE Examples</title>
<para>Most of the Java EE examples can be run the following way. simply cd into the
- appropriate example directory an type <literal>ant deploy</literal>. This will create a
+ appropriate example directory and type <literal>ant deploy</literal>. This will create a
new JBoss AS profile and start the server. When the server is started from a different
window type <literal>ant run</literal> to run the example. Some examples require further
steps, please refer to the examples documentation for further instructions.</para>
Modified: trunk/docs/user-manual/en/ha.xml
===================================================================
--- trunk/docs/user-manual/en/ha.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/ha.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -122,7 +122,7 @@
other purposes, it's necessary to copy the <literal>data</literal> directory
from the live server to the backup server. This means the backup server will
have an identical persistent store to the backup server.</para>
- <para>One a live server has failed over onto a backup server, the old live
+ <para>Once a live server has failed over onto a backup server, the old live
server becomes invalid and cannot just be restarted. To resynchonize the
pair as a working live backup pair again, both servers need to be stopped,
the data copied from the live node to the backup node and restarted
@@ -273,7 +273,7 @@
linkend="examples.non-transaction-failover"/>.</para>
<section id="ha.automatic.failover.noteonreplication">
<title>A Note on Server Replication</title>
- <para>HornetQ does not replicate full server state betwen live and backup servers.
+ <para>HornetQ does not replicate full server state between live and backup servers.
When the new session is automatically recreated on the backup it won't have any
knowledge of messages already sent or acknowledged in that session. Any
in-flight sends or acknowledgements at the time of failover might also be
@@ -294,7 +294,7 @@
<para>Other techniques for multi-threaded active replication exist such as
replicating lock states or replicating thread scheduling but this is very hard
to achieve at a Java level.</para>
- <para>Consequently it xas decided it was not worth massively reducing performance
+ <para>Consequently it has decided it was not worth massively reducing performance
and concurrency for the sake of 100% transparent failover. Even without 100%
transparent failover, it is simple to guarantee <emphasis role="italic">once and
only once</emphasis> delivery, even in the case of failure, by using a
Modified: trunk/docs/user-manual/en/interoperability.xml
===================================================================
--- trunk/docs/user-manual/en/interoperability.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/interoperability.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -119,7 +119,7 @@
</programlisting>
<para>With this configuration, HornetQ will accept Stomp connections over Web Sockets on
the port <literal>61614</literal> with the URL path <literal>/stomp</literal>.
- Web browser can then connect to <literal>ws://<server>:61614/stomp</literal> usin a Web Socket to send and receive Stomp
+ Web browser can then connect to <literal>ws://<server>:61614/stomp</literal> using a Web Socket to send and receive Stomp
messages.</para>
<para>A companion JavaScript library to ease client-side development is available from
<ulink url="http://github.com/jmesnil/stomp-websocket">GitHub</ulink> (please see
Modified: trunk/docs/user-manual/en/large-messages.xml
===================================================================
--- trunk/docs/user-manual/en/large-messages.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/large-messages.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -57,7 +57,7 @@
</section>
<section>
<title>Setting the limits</title>
- <para>Any message large than a certain size is considered a large message. Large messages
+ <para>Any message larger than a certain size is considered a large message. Large messages
will be split up and sent in fragments. This is determined by the parameter <literal
>min-large-message-size</literal></para>
<para>The default value is 100KiB.</para>
@@ -249,7 +249,7 @@
</section>
<section id="large-messages.cache.client">
<title>Cache Large Messages on client</title>
- <para>LargeMessages are transferred by streaming from server to client. The message is
+ <para>Large messages are transferred by streaming from server to client. The message is
broken into smaller packets and as the message is read more packets will be received.
Because of that the body of the large message can be read only once, and by consequence
a received message can be sent to another producer only once. The JMS Bridge for
Modified: trunk/docs/user-manual/en/management.xml
===================================================================
--- trunk/docs/user-manual/en/management.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/management.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -111,7 +111,7 @@
>listPreparedTransactions()</literal> method lists the transactions which
are in the prepared states (the transactions are represented as opaque Base64
Strings.) To commit or rollback a given prepared transaction, the <literal
- >commitPreparedTransaction</literal>() or <literal
+ >commitPreparedTransaction()</literal> or <literal
>rollbackPreparedTransaction()</literal> method can be used to resolve
heuristic transactions. Heuristically completed transactions can be listed
using the <literal>listHeuristicCommittedTransactions()</literal> and <literal
@@ -143,7 +143,7 @@
<listitem>
<para>Modifying roles and permissions for an address</para>
<para>You can add or remove roles associated to a queue using the <literal
- >addRole()</literal> or. <literal>removeRole()</literal> methods. You can
+ >addRole()</literal> or <literal>removeRole()</literal> methods. You can
list all the roles associated to the queue with the <literal
>getRoles()</literal> method</para>
</listitem>
@@ -164,7 +164,7 @@
<para>Expiring, sending to a dead letter address and moving messages</para>
<para>Messages can be expired from a queue by using the <literal
>expireMessages()</literal> method. If an expiry address is defined,
- messages will be be sent to it, otherwise they are discarded. The queue's
+ messages will be sent to it, otherwise they are discarded. The queue's
expiry address can be set with the <literal>setExpiryAddress()</literal>
method.</para>
<para>Messages can also be sent to a dead letter address with the <literal
@@ -325,7 +325,7 @@
>destroyConnectionFactory()</literal> methods. These connection factories
are bound to JNDI so that JMS clients can look them up. If a graphical console
is used to create the connection factories, the transport parameters are
- specified in the text fied input as a comma-separated list of key=value (e.g.
+ specified in the text field input as a comma-separated list of key=value (e.g.
<literal>key1=10, key2="value", key3=false</literal>). If there are multiple
transports defined, you need to enclose the key/value pairs between curly
braces. For example <literal>{key=10}, {key=20}</literal>. In that case, the
@@ -376,7 +376,7 @@
<para>The <literal>ConnectionFactoryControl</literal> exposes JMS
ConnectionFactory configuration through its attributes (e.g. <literal
>getConsumerWindowSize()</literal> to retrieve the consumer window size for
- flow control, <literal>isBlockOnNonDurableSend()</literal> to know wether the
+ flow control, <literal>isBlockOnNonDurableSend()</literal> to know whether the
producers created from the connection factory will block or not when sending
non-durable messages, etc.)</para>
</listitem>
@@ -395,7 +395,7 @@
<para>Expiring, sending to a dead letter address and moving messages</para>
<para>Messages can be expired from a queue by using the <literal
>expireMessages()</literal> method. If an expiry address is defined,
- messages will be be sent to it, otherwise they are discarded. The queue's
+ messages will be sent to it, otherwise they are discarded. The queue's
expiry address can be set with the <literal>setExpiryAddress()</literal>
method.</para>
<para>Messages can also be sent to a dead letter address with the <literal
@@ -444,8 +444,8 @@
<listitem>
<para>Retrieving the queue attributes</para>
<para>The <literal>JMSQueueControl</literal> exposes JMS queue settings through
- its attributes (e.g. <literal>isTemporary()</literal> to know wether the queue
- is temporary or not, <literal>isDurable()</literal> to know wether the queue is
+ its attributes (e.g. <literal>isTemporary()</literal> to know whether the queue
+ is temporary or not, <literal>isDurable()</literal> to know whether the queue is
durable or not, etc.)</para>
</listitem>
<listitem>
@@ -761,7 +761,7 @@
notifications emitted by the server.</para>
<section id="management.notifications.core.configuration">
<title>Configuring The Core Management Notification Address</title>
- <para>the management notification address to receive management notifications is
+ <para>The management notification address to receive management notifications is
configured in <literal>hornetq-configuration.xml</literal>:</para>
<programlisting>
<management-notification-address>hornetq.notifications</management-notification-address>
@@ -953,7 +953,7 @@
</section>
<section>
<title>JMS Connection Factories</title>
- <para>The format for creating connection factories is the same as for JMS Queues and topics apart frm the configuration
+ <para>The format for creating connection factories is the same as for JMS Queues and topics apart from the configuration
being different. For as list of all the connection factory settings see the configuration index </para>
</section>
</section>
Modified: trunk/docs/user-manual/en/message-grouping.xml
===================================================================
--- trunk/docs/user-manual/en/message-grouping.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/message-grouping.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -43,7 +43,7 @@
<section>
<title>Using Core API</title>
<para>The property name used to identify the message group is <literal
- >"_HQ_GROUP_ID""</literal> (or the constant <literal
+ >"_HQ_GROUP_ID"</literal> (or the constant <literal
>MessageImpl.HDR_GROUP_ID</literal>). Alternatively, you can set <literal
>autogroup</literal> to true on the <literal>SessionFactory</literal> which will pick a
random unique id. </para>
@@ -137,7 +137,7 @@
<para>The decision as to where a message should be routed to is initially proposed by the node
that receives the message. The node will pick a suitable route as per the normal clustered
routing conditions, i.e. round robin available queues, use a local queue first and choose a
- queue that has a consumer. If the proposal is excepted by the grouping handlers the node
+ queue that has a consumer. If the proposal is accepted by the grouping handlers the node
will route messages to this queue from that point on, if rejected an alternative route will
be offered and the node will again route to that queue indefinitely. All other nodes will
also route to the queue chosen at proposal time. Once the message arrives at the queue then
Modified: trunk/docs/user-manual/en/messaging-concepts.xml
===================================================================
--- trunk/docs/user-manual/en/messaging-concepts.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/messaging-concepts.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -224,7 +224,7 @@
of one or more of the servers. The degree of support for HA varies between various
messaging systems.</para>
<para>HornetQ provides automatic failover where your sessions are automatically reconnected
- to the backup server on event of live serve failure.</para>
+ to the backup server on event of live server failure.</para>
<para>For more information on HA, please see <xref linkend="ha"/>.</para>
</section>
<section>
Modified: trunk/docs/user-manual/en/persistence.xml
===================================================================
--- trunk/docs/user-manual/en/persistence.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/persistence.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -88,7 +88,7 @@
<para>This journal instance stores all JMS related data, This is basically any JMS Queues, Topics and Connection
Factories and any JNDI bindings for these resources.</para>
<para>Any JMS Resources created via the management API will be persisted to this journal. Any resources
- configured via configuration files will not. The JMS Journal will only becreated if JMS is being used.</para>
+ configured via configuration files will not. The JMS Journal will only be created if JMS is being used.</para>
</listitem>
<listitem>
<para>Message journal.</para>
Modified: trunk/docs/user-manual/en/pre-acknowledge.xml
===================================================================
--- trunk/docs/user-manual/en/pre-acknowledge.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/pre-acknowledge.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -77,6 +77,6 @@
<section>
<title>Example</title>
<para>See <xref linkend="examples.pre-acknowledge"/> for an example which shows how to use
- pre-acknowledgement mode with with JMS.</para>
+ pre-acknowledgement mode with JMS.</para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/security.xml
===================================================================
--- trunk/docs/user-manual/en/security.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/security.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -90,8 +90,6 @@
applies to any address that starts with the string "globalqueues.europe.":</para>
<para>Only users who have the <literal>admin</literal> role can create or delete durable
queues bound to an address that starts with the string "globalqueues.europe."</para>
- <para>Only users who have the <literal>admin</literal> role can create or delete durable
- queues bound to an address that starts with the string "globalqueues.europe."</para>
<para>Any users with the roles <literal>admin</literal>, <literal>guest</literal>, or
<literal>europe-users</literal> can create or delete temporary queues bound to an
address that starts with the string "globalqueues.europe."</para>
@@ -267,7 +265,7 @@
or EJB sets security credentials on the current security context and these are used throughout the call.
If you would like these credentials to be used by HornetQ when sending or consuming messages then
set <literal>allowClientLogin</literal> to true. This will bypass HornetQ authentication and propgate the
- provided Security Context. If you woul like HornetQ to authenticate using the propogated security then set the
+ provided Security Context. If you would like HornetQ to authenticate using the propogated security then set the
<literal>authoriseOnClientLogin</literal> to true also.</para>
<para>There is more info on using the JBoss client login module <ulink
url="http://community.jboss.org/wiki/ClientLoginModule">here</ulink> </para>
Modified: trunk/docs/user-manual/en/thread-pooling.xml
===================================================================
--- trunk/docs/user-manual/en/thread-pooling.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/thread-pooling.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -62,7 +62,7 @@
>hornetq-configuration.xml</literal> with the <literal
>thread-pool-max-size</literal> parameter.</para>
<para>If a value of <literal>-1</literal> is used this signifies that the thread pool
- has no upper bound and new threads will be created on demand if there are enough
+ has no upper bound and new threads will be created on demand if there are not enough
threads available to satisfy a request. If activity later subsides then threads are
timed-out and closed.</para>
<para>If a value of <literal>n</literal> where <literal>n</literal>is a positive integer
@@ -93,7 +93,7 @@
HornetQ-AIO-poller-pool. HornetQ uses one thread per opened file on the journal
(there is usually one).</para>
<para>There is also a single thread used to invoke writes on libaio. We do that to avoid
- context switching on libaio what would cause performance issues. You will find this
+ context switching on libaio that would cause performance issues. You will find this
thread on a thread dump with the prefix HornetQ-AIO-writer-pool.</para>
</section>
</section>
Modified: trunk/docs/user-manual/en/using-server.xml
===================================================================
--- trunk/docs/user-manual/en/using-server.xml 2010-05-26 08:17:33 UTC (rev 9265)
+++ trunk/docs/user-manual/en/using-server.xml 2010-05-26 11:50:26 UTC (rev 9266)
@@ -38,7 +38,7 @@
parameters and start the JBoss Microcontainer. The Microcontainer is a light weight
container used to deploy the HornetQ POJO's</para>
<para>To stop the server you'll also find a unix/linux script <literal>stop.sh</literal> and
- a windows batch file <literal>run.bat</literal></para>
+ a windows batch file <literal>stop.bat</literal></para>
<para>To run on Unix/Linux type <literal>./stop.sh</literal></para>
<para>To run on Windows type <literal>stop.bat</literal></para>
<para>Please note that HornetQ requires a Java 6 or later runtime to run.</para>
More information about the hornetq-commits
mailing list