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 @@ &lt;config-property-value&gt;host=127.0.0.1;port=5446&lt;/config-property-value&gt; &lt;/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" <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" <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 - 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 </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 </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://&lt;server&gt;:61614/stomp</literal> usin a Web Socket to send and receive Stomp + Web browser can then connect to <literal>ws://&lt;server&gt;: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</u... (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 <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 @@ 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 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 </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 - 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 @@ 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 - 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 - 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> &lt;management-notification-address&gt;hornetq.notifications&lt;/management-notification-address&gt; @@ -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 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... </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 @@ <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>