[hornetq-commits] JBoss hornetq SVN: r9085 - branches/HnetQ_323_cn/docs/user-manual/zh.
do-not-reply at jboss.org
do-not-reply at jboss.org
Fri Apr 9 10:36:35 EDT 2010
Author: gaohoward
Date: 2010-04-09 10:36:35 -0400 (Fri, 09 Apr 2010)
New Revision: 9085
Modified:
branches/HnetQ_323_cn/docs/user-manual/zh/last-value-queues.xml
branches/HnetQ_323_cn/docs/user-manual/zh/message-grouping.xml
branches/HnetQ_323_cn/docs/user-manual/zh/queue-attributes.xml
branches/HnetQ_323_cn/docs/user-manual/zh/scheduled-messages.xml
Log:
done
Modified: branches/HnetQ_323_cn/docs/user-manual/zh/last-value-queues.xml
===================================================================
--- branches/HnetQ_323_cn/docs/user-manual/zh/last-value-queues.xml 2010-04-09 14:04:00 UTC (rev 9084)
+++ branches/HnetQ_323_cn/docs/user-manual/zh/last-value-queues.xml 2010-04-09 14:36:35 UTC (rev 9085)
@@ -17,30 +17,26 @@
<!-- permitted by applicable law. -->
<!-- ============================================================================= -->
<chapter id="last-value-queues">
- <title>Last-Value Queues</title>
- <para>Last-Value queues are special queues which discard any messages when a newer message with
- the same value for a well-defined Last-Value property is put in the queue. In other words, a
- Last-Value queue only retains the last value.</para>
- <para>A typical example for Last-Value queue is for stock prices, where you are only interested
- by the latest value for a particular stock.</para>
+ <title>最新值队列（Last-Value Queues）</title>
+ <para>最新值队列是一种特殊的队列。当一个新消息到达一个最新值队列时，它会将所有与该消息定义的Last-Value相同的旧消息
+ 抛弃。换句话说，只有最新的消息被保留下来。</para>
+ <para>一个典型的用例是股价信息，通常你只关心一支股票的最新价格。</para>
<section>
- <title>Configuring Last-Value Queues</title>
- <para>Last-value queues are defined in the address-setting configuration:</para>
+ <title>最新值队列的配置</title>
+ <para>最新值队列的配置在address-setting内：</para>
<programlisting>
<address-setting match="jms.queue.lastValueQueue">
<last-value-queue>true</last-value-queue>
</address-setting>
</programlisting>
- <para>By default, <literal>last-value-queue</literal> is false. Address wildcards can be used
- to configure Last-Value queues for a set of addresses (see <xref linkend="wildcard-syntax"
- />).</para>
+ <para>默认的<literal>last-value-queue</literal>值是false。可以使用通配符来匹配地址。
+ （参见 <xref linkend="wildcard-syntax"/>）。</para>
</section>
<section>
- <title>Using Last-Value Property</title>
- <para>The property name used to identify the last value is <literal>"_HQ_LVQ_NAME"</literal>
- (or the constant <literal>Message.HDR_LAST_VALUE_NAME</literal> from the Core API).</para>
- <para>For example, if two messages with the same value for the Last-Value property are sent to
- a Last-Value queue, only the latest message will be kept in the queue:</para>
+ <title>使用Last-Value参数</title>
+ <para>用来标识最新值的参数名是<literal>"_HQ_LVQ_NAME"</literal>
+ （相当于核心API中定义的常量<literal>Message.HDR_LAST_VALUE_NAME</literal>）。</para>
+ <para>如果两个消息具有相同的Last-Value值，那么较新的消息就会保留，另外一个被丢弃：</para>
<programlisting>
// send 1st message with Last-Value property set to STOCK_NAME
TextMessage message =
@@ -63,8 +59,8 @@
</programlisting>
</section>
<section>
- <title>Example</title>
- <para>See <xref linkend="examples.last-value-queue"/> for an example which shows how last
- value queues are configured and used with JMS.</para>
+ <title>例子</title>
+ <para>参见<xref linkend="examples.last-value-queue"/>。它展示的是在JMS应用中来配置和使用
+ 最新值队列。</para>
</section>
</chapter>
Modified: branches/HnetQ_323_cn/docs/user-manual/zh/message-grouping.xml
===================================================================
--- branches/HnetQ_323_cn/docs/user-manual/zh/message-grouping.xml 2010-04-09 14:04:00 UTC (rev 9084)
+++ branches/HnetQ_323_cn/docs/user-manual/zh/message-grouping.xml 2010-04-09 14:36:35 UTC (rev 9085)
@@ -17,41 +17,31 @@
<!-- permitted by applicable law. -->
<!-- ============================================================================= -->
<chapter id="message-grouping">
- <title>Message Grouping</title>
- <para>Message groups are sets of messages that have the following characteristics:</para>
+ <title>消息分组</title>
+ <para>消息组是具有下列特性的消息集合：</para>
<itemizedlist>
<listitem>
- <para>Messages in a message group share the same group id, i.e. they have same group
- identifier property (<literal>JMSXGroupID</literal> for JMS, <literal
- >_HQ_GROUP_ID</literal> for HornetQ Core API).</para>
+ <para>在一个消息组中的消息有相同的组标识（id），即它们的<literal>JMSXGroupID</literal>（JMS）或
+ <literal>_HQ_GROUP_ID</literal>（HornetQ核心）的值相同。</para>
</listitem>
<listitem>
- <para>Messages in a message group are always consumed by the same consumer, even if there
- are many consumers on a queue. They pin all messages with the same group id to the same
- consumer. If that consumer closes another consumer is chosen and will receive all
- messages with the same group id.</para>
+ <para>不管存在多少个接收者（consumer），一个消息组的所有消息总是被同一个接收者所接收。一个组id总是
+ 与同一个接收者相关联。如果这个接收者被关闭，另外一个接收者就被选中来代替它接收该消息组的消息。</para>
</listitem>
</itemizedlist>
- <para>Message groups are useful when you want all messages for a certain value of the property to
- be processed serially by the same consumer.</para>
- <para>An example might be orders for a certain stock. You may want orders for any particular
- stock to be processed serially by the same consumer. To do this you can create a pool of
- consumers (perhaps one for each stock, but less will work too), then set the stock name as the
- value of the _HQ_GROUP_ID property.</para>
- <para>This will ensure that all messages for a particular stock will always be processed by the
- same consumer.</para>
+ <para>消息组在需要同一个接收者按顺序处理某类消息的时候很有用。</para>
+ <para>一支股票的订购就是一个例子。某支股票的订单需要同一个接收者按顺序处理。于是可以每支股票有一个接收者
+ 来处理（也可以用少一些的接收者），然后将每支股票的名字设在消息的_HQ_GROUP_ID参数中。</para>
+ <para>这样可以保证一支股票的消息只被同一个接收者处理。</para>
<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
- >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>
+ <title>使用核心接口</title>
+ <para>用来标识一个消息组的参数是 <literal>"_HQ_GROUP_ID""</literal> （或者相应的常量<literal
+ >MessageImpl.HDR_GROUP_ID</literal>）。另一种方法是在<literal>SessionFactory</literal>
+ 中将<literal>autogroup</literal>设置为true。这样做的话组id是随机给出的。</para>
</section>
<section id="message-grouping.jmsconfigure">
- <title>Using JMS</title>
- <para>The property name used to identify the message group is <literal
- >JMSXGroupID</literal>.</para>
+ <title>使用JMS</title>
+ <para>用来标识一个消息组的参数是<literal>JMSXGroupID</literal>。</para>
<programlisting>
// send 2 messages in the same group to ensure the same
// consumer will receive both
@@ -63,9 +53,8 @@
message.setStringProperty("JMSXGroupID", "Group-0");
producer.send(message);
</programlisting>
- <para>Alternatively, you can set <literal>autogroup</literal> to true on the <literal
- >HornetQConnectonFactory</literal> which will pick a random unique id. This can also be
- set in the <literal>hornetq-jms.xml</literal> file like this:</para>
+ <para>另一个方法是将<literal>HornetQConnectonFactory</literal>的<literal>autogroup</literal>
+ 属性设为true，或者在<literal>hornetq-jms.xml</literal>文件中进行配置：</para>
<programlisting><connection-factory name="ConnectionFactory">
<connectors>
<connector-ref connector-name="netty-connector"/>
@@ -75,11 +64,9 @@
</entries>
<autogroup>true</autogroup>
</connection-factory></programlisting>
- <para>Alternatively you can set the group id via the connection factory. All messages sent
- with producers created via this connection factory will set the <literal
- >JMSXGroupID</literal> to the specified value on all messages sent. To configure the
- group id set it on the connection factory in the <literal>hornetq-jms.xml</literal> config
- file as follows
+ <para>还可以通过连接工厂来设置组id。来自这个连接工厂的所有的发送者（producer）发送的消息的<literal
+ >JMSXGroupID</literal>将具有指定的值。这种方法需要在<literal>hornetq-jms.xml</literal>
+ 文件中作如下配置：
<programlisting>
<connection-factory name="ConnectionFactory">
<connectors>
@@ -93,32 +80,27 @@
</programlisting></para>
</section>
<section>
- <title>Example</title>
- <para>See <xref linkend="examples.message-group"/> for an example which shows how message
- groups are configured and used with JMS.</para>
+ <title>例子</title>
+ <para>参见<xref linkend="examples.message-group"/>。这个例子展示的是在JMS中如何配置与使用消息组。</para>
</section>
<section>
- <title>Example</title>
- <para>See <xref linkend="examples.message-group2"/> for an example which shows how message
- groups are configured via a connection factory.</para>
+ <title>例子</title>
+ <para><xref linkend="examples.message-group2"/>是另外一个消息组的例子，在这个例子中通过配置连接工厂
+ 来使用消息组。</para>
</section>
<section>
- <title> Clustered Grouping</title>
- <para>Using message groups in a cluster is a bit more complex. This is because messages with a
- particular group id can arrive on any node so each node needs to know about which group
- id's are bound to which consumer on which node. The consumer handling messages for a
- particular group id may be on a different node of the cluster, so each node needs to know
- this information so it can route the message correctly to the node which has that consumer. </para>
- <para>To solve this there is the notion of a grouping handler. Each node will have its own
- grouping handler and when a messages is sent with a group id assigned, the handlers will
- decide between them which route the message should take.</para>
- <para>There are 2 types of handlers; Local and Remote. Each cluster should choose 1 node to
- have a local grouping handler and all the other nodes should have remote handlers- it's the
- local handler that actually makes the decsion as to what route should be used, all the
- other remote handlers converse with this. Here is a sample config for both types of
- handler, this should be configured in the <emphasis role="italic"
- >hornetq-configuration.xml</emphasis>
- file.<programlisting> <grouping-handler name="my-grouping-handler">
+ <title>集群中的消息组</title>
+ <para>在集群中使用消息组是相对比较复杂的。这是因在在集群中，一个消息组中的消息有可能被送到集群中的任一全节点，
+ 这就要求每个节点都要知道这个消息是属于哪个节点上的哪个接收者（consumer）。一个消息组的消息往往会被发送到
+ 集群中的一个节点，而该消息组的接收者在另一个节点上。每个节点都要知道这些细节以便能将消息正确路由到所属接收
+ 者所在的节点上。</para>
+ <para>为了解决上述问题，我们使用了消息组处理器。每个节点都有一个自己的消息组处理器。当一个带有组id的消息收到时，
+ 这些节点的消息组处理器就会协同作出决定该如何对这个消息进行路由。</para>
+ <para>消息组处理器有两种：本地消息组处理器和远程消息组处理器。在一个集群中要选择一个节点作为本地消息组处理器的
+ 节点，集群中所有其它的节点都持有远程消息组处理器。在集群中由本地消息组处理器最終决定消息怎样路由，其它的远程
+ 处理器配合本地处理器完成决策。消息组处理器的配置在<emphasis role="italic">hornetq-configuration.xml</emphasis>
+ 文件中，下面就是一个例子：
+<programlisting> <grouping-handler name="my-grouping-handler">
<type>LOCAL</type>
<address>jms</address>
<timeout>5000</timeout>
@@ -129,57 +111,39 @@
<address>jms</address>
<timeout>5000</timeout>
</grouping-handler></programlisting></para>
- <para>The <emphasis role="italic">address</emphasis> attribute refers to a cluster connection
- and the address it uses, refer to the clustering section on how to configure clusters. The
- <emphasis role="italic">timeout</emphasis> attribute referes to how long to wait for a
- decision to be made, an exception will be thrown during the send if this timeout is
- reached, this ensures that strict ordering is kept.</para>
- <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
- 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
- normal single server message group semantics take over and the message is pinned to a
- consumer on that queue.</para>
- <para>You may have noticed that there is a single point of failure with the single local
- handler. If this node crashes then no decisions will be able to be made. Any messages sent
- will be not be delivered and an exception thrown. To avoid this happening Local Handlers
- can be replicated on another backup node. Simple create your back up node and configure it
- with the same Local handler.</para>
+ <para><emphasis role="italic">address</emphasis>属性表示一个集群的连接以及它使用的地址。有关如何配置集群
+ 参见集群章节。<emphasis role="italic">timeout</emphasis>属性代表做出路由决定所需要等待的时间。如果超过
+ 了这个时间还没有做出决定，则会抛出异常。这可以保证严格的顺序。</para>
+ <para>收到消息的节点会首先提出一个消息路由的建议。它采用轮询方式来选择一个合适的路由。它首先选择一个本地的队列，之后
+ 再选择一个有接收者的队列。如果这个建议被所有组处理器接受，消息就会被路由到所选的队列。如果被拒绝就提出另一个路
+ 由方案，如此反复直到方案被接受为止。队列选择后所有其它的节点都将消息路由到这个队列。这样所有的消息组的消息在一个
+ 节点上进行处理，也就是该节点上的接收者接收所有的同组的消息。</para>
+ <para>由于只有一个本地处理器，如果它的节点出现故障则无法做出决定。这时所有的消息将不能被传递，并且会抛出异常。
+ 为了避免这一单点故障，本地处理器可以在备份节点上有一个复本。只要创建备份节点并配置一个相同的本地处理器即可。</para>
<para/>
<section>
- <title>Clustered Grouping Best Practices</title>
- <para>Some best practices should be followed when using clustered grouping:<orderedlist>
+ <title>集群消息组的最佳使用惯例</title>
+ <para>下面是一些很好的建议：<orderedlist>
<listitem>
- <para>Make sure your consumers are distributed evenly across the different nodes
- if possible. This is only an issue if you are creating and closing consumers
- regularly. Since messages are always routed to the same queue once pinned,
- removing a consumer from this queue may leave it with no consumers meaning the
- queue will just keep receiving the messages. Avoid closing consumers or make
- sure that you always have plenty of consumers, i.e., if you have 3 nodes have 3
- consumers.</para>
+ <para>尽可能使接收者均匀分布在不同的节点上。由于消息组的消息总是传递到同一个队列的同一个接收者，
+ 如果你经常性地创建与关闭接收者，就可能出现消息由于没有接收者而传递不出去，造成消息在队列中
+ 不断积累的情况。因此，尽量要避免关闭接收者，或者确保有足够数量的接收者。例如，如果你的集群
+ 有3个节点，那么就创建3个接收者。</para>
</listitem>
<listitem>
- <para>Use durable queues if possible. If queues are removed once a group is bound
- to it, then it is possible that other nodes may still try to route messages to
- it. This can be avoided by making sure that the queue is deleted by the session
- that is sending the messages. This means that when the next message is sent it
- is sent to the node where the queue was deleted meaning a new proposal can
- succesfully take place. Alternatively you could just start using a different
- group id.</para>
+ <para>尽可能使用持久型队列。如果消息组的消息与一个队列绑定，一旦这个队列被删除，其它节点可能仍然
+ 尝试向这个已删除的队列路由消息。为避免这种情况，要确保这个队列由发送消息的会话来删除。这样如果
+ 下一个消息发出后发现原来的队列被删除，新的路由建议就会提出。另外一种方案是你可以重新使用一个不
+ 同的组ID。</para>
</listitem>
<listitem>
- <para>Always make sure that the node that has the Local Grouping Handler is
- replicated. These means that on failover grouping will still occur.</para>
+ <para>一定要确保本地的消息组处理器有备份。这样在有故障时消息组仍然可以正常工作。</para>
</listitem>
</orderedlist></para>
</section>
<section>
- <title>Clustered Grouping Example</title>
- <para>See <xref linkend="examples.clustered.grouping"/> for an example of how to configure
- message groups with a HornetQ cluster</para>
+ <title>集群消息组例子</title>
+ <para>参见<xref linkend="examples.clustered.grouping"/>，这个例子给出了如何在HornetQ集群中配置消息组。</para>
</section>
</section>
</chapter>
Modified: branches/HnetQ_323_cn/docs/user-manual/zh/queue-attributes.xml
===================================================================
--- branches/HnetQ_323_cn/docs/user-manual/zh/queue-attributes.xml 2010-04-09 14:04:00 UTC (rev 9084)
+++ branches/HnetQ_323_cn/docs/user-manual/zh/queue-attributes.xml 2010-04-09 14:36:35 UTC (rev 9085)
@@ -17,34 +17,27 @@
<!-- permitted by applicable law. -->
<!-- ============================================================================= -->
<chapter id="queue-attributes">
- <title>Queue Attributes</title>
- <para>Queue attributes can be set in one of two ways. Either by configuring them using the
- configuration file or by using the core API. This chapter will explain how to configure each
- attribute and what effect the attribute has.</para>
+ <title>队列属性</title>
+ <para>有两种方法可以设置队列的属性。一种使用配置文件，另一种使用核心接口（core API）。
+ 本章讲述这些属性的配置以及这些属性的作用。</para>
<section id="predefined.queues">
- <title>Predefined Queues</title>
- <para>Queues can be predefined via configuration at a core level or at a JMS level. Firstly
- lets look at a JMS level.</para>
- <para>The following shows a queue predefined in the <literal>hornetq-jms.xml</literal>
- configuration file.</para>
+ <title>预定义的队列</title>
+ <para>通过配置可以定义队列。队列的定义可以在核心层定义，也可以在JMS层来定义。首先我们看一下JMS层。</para>
+ <para>下面就是一个在<literal>hornetq-jms.xml</literal>中定义的一个队列的例子：</para>
<programlisting><queue name="selectorQueue">
<entry name="/queue/selectorQueue"/>
<selector string="color='red'"/>
<durable>true</durable>
</queue></programlisting>
- <para>This name attribute of queue defines the name of the queue. When we do this at a jms
- level we follow a naming convention so the actual name of the core queue will be
- <literal>jms.queue.selectorQueue</literal>.</para>
- <para>The entry element configures the name that will be used to bind the queue to JNDI.
- This is a mandatory element and the queue can contain multiple of these to bind the same
- queue to different names.</para>
- <para>The selector element defines what JMS message selector the predefined queue will have.
- Only messages that match the selector will be added to the queue. This is an optional
- element with a default of null when omitted.</para>
- <para>The durable element specifies whether the queue will be persisted. This again is
- optional and defaults to true if omitted.</para>
- <para>Secondly a queue can be predefined at a core level in the <literal
- >hornetq-configuration.xml</literal> file. The following is an example.</para>
+ <para>这个队列的name属性定义了队列的名字。例子中我们采用了一种命名的惯例，因些对应的核心队列的名字是
+ <literal>jms.queue.selectorQueue</literal>。</para>
+ <para>在entry单元内定义的名字用来将队列绑定于JNDI。这是必不可少的。一个队列可以有多个entry定义，每个
+ 定义中的名字都绑定到同一个队列。</para>
+ <para>selector单元定义的是队列的选择器。定义了选择器后，只有与选择器相匹配的消息才能被加到队列中。
+ 这是一个可选项。如果没有定义选择器，队列将默认没有选择器。</para>
+ <para>durable定义了队列是否是一个可持久的队列。这也是一个可选项，默认值是true。</para>
+ <para>如果在核心层定义队列，则使用<literal>hornetq-configuration.xml</literal>文件。
+ 下面是一个例子：</para>
<programlisting><queues>
<queue name="jms.queue.selectorQueue">
<address>jms.queue.selectorQueue</address>
@@ -52,43 +45,36 @@
<durable>true</durable>
</queue>
</queues></programlisting>
- <para>This is very similar to the JMS configuration, with 3 real differences which
- are.</para>
+ <para>它的配置与JMS的配置很相似，但有三个不同之处：</para>
<orderedlist>
<listitem>
- <para>The name attribute of queue is the actual name used for the queue with no
- naming convention as in JMS.</para>
+ <para>队列的name属性是队列的真正名字，不是JMS中的名字。</para>
</listitem>
<listitem>
- <para>The address element defines what address is used for routing messages.</para>
+ <para>address一项定义了消息路由的地址。</para>
</listitem>
<listitem>
- <para>There is no entry element.</para>
+ <para>没有entry单元。</para>
</listitem>
<listitem>
- <para>The filter uses the <emphasis>Core filter syntax</emphasis> (described in
- <xref linkend="filter-expressions"/>), <emphasis>not</emphasis> the JMS
- selector syntax.</para>
+ <para>filter的定义使用<emphasis>核心过滤器语法</emphasis> （在
+ <xref linkend="filter-expressions"/>中描述），不是JMS的选择器语法。</para>
</listitem>
</orderedlist>
</section>
<section>
- <title>Using the API</title>
- <para>Queues can also be created using the core API or the management API.</para>
- <para>For the core API, queues can be created via the <literal
- >org.hornetq.api.core.client.ClientSession</literal> interface. There are multiple
- <literal>createQueue</literal> methods that support setting all of the previously
- mentioned attributes. There is one extra attribute that can be set via this API which is
- <literal>temporary</literal>. setting this to true means that the queue will be
- deleted once the session is disconnected.</para>
- <para>Take a look at <xref linkend="management"/> for a description of the management API
- for creating queues.</para>
+ <title>使用接口（API）创建队列</title>
+ <para>队列还可以使用核心接口或管理接口来创建。</para>
+ <para>核心接口的<literal>org.hornetq.api.core.client.ClientSession</literal>接口可以用来
+ 创建队列。它有几个<literal>createQueue</literal>方法，可以在创建队列时对上述的属性进行设置。
+ 除此之外，还有一个额外的属性<literal>temporary</literal>可以设置。如果将其设为true，
+ 那么队列在会话断开时将被删除。</para>
+ <para>在<xref linkend="management"/>中讲述了如何用管理接口来创建队列。</para>
</section>
<section id="queue-attributes.address-settings">
- <title>Configuring Queues Via Address Settings</title>
- <para>There are some attributes that are defined against an address wildcard rather than a
- specific queue. Here an example of an <literal>address-setting</literal> entry that
- would be found in the <literal>hornetq-configuration.xml</literal> file.</para>
+ <title>通过地址设置来配置队列属性</title>
+ <para>有些属性的定义中地址可以使用通配符。下面是<literal>hornetq-configuration.xml</literal>
+ 文件中的一个<literal>address-setting</literal>的配置例子。</para>
<programlisting><address-settings>
<address-setting match="jms.queue.exampleQueue">
<dead-letter-address>jms.queue.deadLetterQueue</dead-letter-address>
@@ -103,43 +89,32 @@
<address-full-policy>PAGE</address-full-policy>
</address-setting>
</address-settings></programlisting>
- <para>The idea with address settings, is you can provide a block of settings which will be
- applied against any adresses that match the string in the <literal>match</literal> attribute. In the
- above example the settings would only be applied to any addresses which exactly match
- the address <literal>jms.queue.exampleQueue</literal>, but you can also use wildcards to apply sets of
- configuration against many addresses. The wildcard syntax used is described <link linkend="wildcard-syntax">here</link>.</para>
- <para>For example, if you used the <literal>match</literal> string <literal>jms.queue.#</literal> the settings would be applied
- to all addresses which start with <literal>jms.queue.</literal> which would be all JMS queues.</para>
- <para>The meaning of the specific settings are explained fully throughout the user manual, however here is a brief
- description with a link to the appropriate chapter if available. </para>
- <para><literal>max-delivery-attempts</literal> defines how many time a cancelled message can
- be redelivered before sending to the <literal>dead-letter-address</literal>. A full
- explanation can be found <link linkend="undelivered-messages.configuring"
- >here</link>.</para>
- <para><literal>redelivery-delay</literal> defines how long to wait before attempting
- redelivery of a cancelled message. see <link linkend="undelivered-messages.delay"
- >here</link>.</para>
- <para><literal>expiry-address</literal> defines where to send a message that has expired.
- see <link linkend="message-expiry.configuring">here</link>.</para>
- <para><literal>last-value-queue</literal> defines whether a queue only uses last values or
- not. see <link linkend="last-value-queues">here</link>.</para>
- <para><literal>max-size-bytes</literal> and <literal>page-size-bytes</literal> are used to
- set paging on an address. This is explained <link linkend="paging">here</link>.</para>
- <para><literal>redistribution-delay</literal> defines how long to wait when the last
- consumer is closed on a queue before redistributing any messages. see <link
- linkend="clusters.message-redistribution">here</link>.</para>
- <para><literal>send-to-dla-on-no-route</literal>. If a message is sent to an address, but the server does not route it to any queues,
- for example, there might be no queues bound to that address, or none of the queues have filters that match, then normally that message
- would be discarded. However if this parameter is set to true for that address, if the message is not routed to any queues it will instead
- be sent to the dead letter address (DLA) for that address, if it exists.</para>
- <para><literal>address-full-policy</literal>. This attribute can have one of the following values: PAGE, DROP or BLOCK and determines what happens when
- an address where <literal>max-size-bytes</literal> is specified becomes full. The default value is PAGE. If the value is PAGE then further messages will be paged to disk.
- If the value is DROP then further messages will be silently dropped.
- If the value is BLOCK then client message producers will block when they try and send further messages.
-
- See the following chapters for more info <xref linkend="flow-control"/>, <xref linkend="paging"/>.
+ <para>通过上述的地址设定可以将多个属性应用于所有与<literal>match</literal>属性相匹配的地址。
+ 上面例子中所定义的属性应用于<literal>jms.queue.exampleQueue</literal>的地址。如果使用
+ 通配符，就可以将这些属性应用于一组匹配的地址。通配符的详细说明在<link linkend="wildcard-syntax">这里</link>。</para>
+ <para>例如在<literal>match</literal>中定义字符串<literal>jms.queue.#</literal>，那么
+ 定义的属性就会应用于所有以<literal>jms.queue.</literal>开头的地址－－即所有的JMS队列。</para>
+ <para>这些属性在本手册的各个地方有相应的介绍。在此处给出了简单的解释各它所在章的连接。</para>
+ <para><literal>max-delivery-attempts</literal>定义了最大重传递的次数。一个消息如果反复传递超过
+ 了这个值将会被发往死信地址<literal>dead-letter-address</literal>。相关的完整的解释在
+ <link linkend="undelivered-messages.configuring">这里</link>。</para>
+ <para><literal>redelivery-delay</literal>定义了重新传递的延迟。它控制HornetQ在重新
+ 传递一个被取消的消息时要等待的时间。参见<link linkend="undelivered-messages.delay"
+ >这里</link>。</para>
+ <para><literal>expiry-address</literal>定义了过期消息的发送地址。参见<link linkend="message-expiry.configuring">这里</link>。</para>
+ <para><literal>last-value-queue</literal> 定义一个队列是否使用最新值。参见<link linkend="last-value-queues">这里</link>。</para>
+ <para><literal>max-size-bytes</literal>和<literal>page-size-bytes</literal>用来设置地址的分页转存功能。
+ 它们在<link linkend="paging">这里</link>有详细的解释。</para>
+ <para><literal>redistribution-delay</literal>定义了当最后一个接收者关闭时重新分配队列消息前所等待的时间。
+ 参见<link linkend="clusters.message-redistribution">这里</link>。</para>
+ <para><literal>send-to-dla-on-no-route</literal>。当一个消息被送到某个地址时，可能不会被路由到任何一个队列。
+ 例如该地址没有绑定任何队列的情况，或者它所有的队列的选择器与该消息不匹配时。这样的消息通常情况下会被丢弃。这时
+ 如果将这个参数设为true，则如果这个地址配置了死信地址的话，这样的消息就会被发送到该地址的死信地址（DLA）。</para>
+ <para><literal>address-full-policy</literal>。这个属性有三个可能的值：PAGE、 DROP 或 BLOCK。它决定了
+ 如果地址的消息所占用的内存达到了<literal>max-size-bytes</literal>所定义的值时，如何处理后继到来的消息。
+ 默认值是PAGE，就是将后续的消息分页转存到磁盘上。DROP则表示丢弃后续的消息。BLOCK表示阻塞消息的发送方发送后续
+ 的消息。参见<xref linkend="flow-control"/>和<xref linkend="paging"/>。
</para>
-
-
+
</section>
</chapter>
Modified: branches/HnetQ_323_cn/docs/user-manual/zh/scheduled-messages.xml
===================================================================
--- branches/HnetQ_323_cn/docs/user-manual/zh/scheduled-messages.xml 2010-04-09 14:04:00 UTC (rev 9084)
+++ branches/HnetQ_323_cn/docs/user-manual/zh/scheduled-messages.xml 2010-04-09 14:36:35 UTC (rev 9085)
@@ -17,18 +17,15 @@
<!-- permitted by applicable law. -->
<!-- ============================================================================= -->
<chapter id="scheduled-messages">
- <title>Scheduled Messages</title>
- <para>Scheduled messages differ from normal messages in that they won't be delivered until a
- specified time in the future, at the earliest.</para>
- <para>To do this, a special property is set on the message before sending it.</para>
+ <title>定期消息</title>
+ <para>与普通消息不同，定期消息是在未来某个指定时间发送的消息。</para>
+ <para>为了创建定期消息，需要设定一个特殊的参数.</para>
<section>
- <title>Scheduled Delivery Property</title>
- <para>The property name used to identify a scheduled message is <literal
- >"_HQ_SCHED_DELIVERY"</literal> (or the constant <literal
- >Message.HDR_SCHEDULED_DELIVERY_TIME</literal>).</para>
- <para>The specified value must be a <literal>long</literal> corresponding to the time the
- message must be delivered (in milliseconds). An example of sending a scheduled message
- using the JMS API is as follows.</para>
+ <title>定期传递参数</title>
+ <para>用来标识一个定期消息的参数是<literal
+ >"_HQ_SCHED_DELIVERY"</literal> （相当于常量<literal
+ >Message.HDR_SCHEDULED_DELIVERY_TIME</literal>）。</para>
+ <para>这个参数的值必须是一个长整型，单位是毫秒。下面例子给出了使用JMS接口创建定期消息的方法：</para>
<programlisting>
TextMessage message =
session.createTextMessage("This is a scheduled message message which will be delivered
@@ -41,12 +38,10 @@
// message will not be received immediately but 5 seconds later
TextMessage messageReceived = (TextMessage) consumer.receive();
</programlisting>
- <para>Scheduled messages can also be sent using the core API, by setting the same property on
- the core message before sending.</para>
+ <para>也可以使用核心接口来发送定期消息。它只需要将同样的参数设定到核心消息上即可。</para>
</section>
<section>
- <title>Example</title>
- <para>See <xref linkend="examples.scheduled-message"/> for an example which shows how
- scheduled messages can be used with JMS.</para>
+ <title>例子</title>
+ <para>参见<xref linkend="examples.scheduled-message"/>，它是一个JMS使用定期消息的例子。</para>
</section>
</chapter>
More information about the hornetq-commits
mailing list