Return-Path: X-Original-To: apmail-activemq-commits-archive@www.apache.org Delivered-To: apmail-activemq-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7AFDE17541 for ; Mon, 10 Nov 2014 16:32:14 +0000 (UTC) Received: (qmail 48971 invoked by uid 500); 10 Nov 2014 16:32:14 -0000 Delivered-To: apmail-activemq-commits-archive@activemq.apache.org Received: (qmail 48854 invoked by uid 500); 10 Nov 2014 16:32:14 -0000 Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list commits@activemq.apache.org Received: (qmail 47381 invoked by uid 99); 10 Nov 2014 16:32:13 -0000 Received: from tyr.zones.apache.org (HELO tyr.zones.apache.org) (140.211.11.114) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Nov 2014 16:32:13 +0000 Received: by tyr.zones.apache.org (Postfix, from userid 65534) id 204948C1586; Mon, 10 Nov 2014 16:32:13 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: jbertram@apache.org To: commits@activemq.apache.org Date: Mon, 10 Nov 2014 16:32:37 -0000 Message-Id: In-Reply-To: <8b738e60a5d74a9c9614de4f578bb10f@git.apache.org> References: <8b738e60a5d74a9c9614de4f578bb10f@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [26/51] [partial] activemq-6 git commit: ACTIVEMQ6-1 - Initial HornetQ Donation Commit http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/examples.xml ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/examples.xml b/docs/user-manual/zh/examples.xml new file mode 100644 index 0000000..430dc64 --- /dev/null +++ b/docs/user-manual/zh/examples.xml @@ -0,0 +1,427 @@ + + + + + + + + + + + + + + + + + + + + 例子 + 在HornetQ的发布包中有超过70个不同的例子。这些例子直接可以运行。它们分别展示了HornetQ所具有的各种功能。 + 所有的例子都在HornetQ发布包的 examples目录下。所有的例子被分成了两大类: + JMS例子和内核例子。JMS例子展现的是JMS的各种功能,内核的例子则展示的是内核API的功能。 + + 此外HornetQ还提供了一些Java EE的例子,这些例子需要JBoss应用服务器才能运行。 +
+ JMS 例子 + 要运行一个JMS例子,只要进入到相应例子的子目录,运行 ./build.sh (或者 + 在Windows平台上运行build.bat)即可。 + 下面列出的这些JMS例子并配有简要的说明。 +
+ 应用层的失效备援(Failover) + HornetQ支持应用层的失效备援。这在服务器端没有复制(replication)配置的情况下是很有用的。 + 应用程序可以注册一个JMS ExceptionListener。当HornetQ检测到连接故障时,它会 + 通知这个注册的Listener。 + 这个ExceptionListener在接到HornetQ的通知后可以与其它的节点创建 + 新的连接、会话等对象,以使应用程序能继续运行。 + 应用层的失效备援是实现高可获得性(HA)的一种方法。它与自动失效备援不同之处在于它需要编写额外的代码。 + 同时由于发生故障时旧的会话结束,这会造成那些还没来得及提交的工作丢失,还会造成任何没有通知的消息被重发。 +
+
+ 内核桥(Bridge)例子 + bridge例子展示的是将一个内核桥部署到一个服务器上,从本地的queue接收消息并将其转发到 + 另一服务器的地址上。 + 内核的bridge可用来在两个互相分开的HornetQ的服务器间建立一个消息流。它可以处理临时性的连接故障,特别适用于 + 不可靠的网络的情况。广域网就是一个例子。 +
+
+ 浏览器(Browser) + browser例子展示的是在HornetQ中如何使用JMS QueueBrowser + 有关JMS queue的概念在JMS 1.1 specification有明确的定义,这里就不再叙述。 + 一个QueueBrowser可以用来观察queue中的消息而影响它们。它可以观察queue中的全部 + 消息,也可以定义一个选择器(selector)来选择性地察看消息。 +
+
+ Client Kickoff + client-kickoff例子展示的是如何利用JMX管理接口通过已知的IP地址来断开客户端的连接。 +
+
+ 客户端的负载均衡 + client-side-load-balancing例子展示的是通过一个JMS连接可以在集群的不同节点上创建 + 会话。也就是说HornetQ可以对客户端的会话创建进行集群内的负载均衡。 +
+
+ 集群分组 + 与分组(grouping)例子相似,只是本例所展示的是集群的情况。发向不同节点的具有相同组id的消息 + 都会传送到同一个节点上的同一个接收者(consumer)。 +
+
+ 集群队列 + clustered-queue 例子将一个JMS queue部署到两个节点上。这两个节点组成一个集群。 + 我们在每个节点上各创建一个接收者(consumer),但只在其中一个节点上创建一个发送者(producer)。利用发送者 + 发送一些消息,然后确认两个接收者以轮换方式(round-robin)接收这些消息。 +
+
+ 单机集群 + clustered-standalone例子所展示的是如何在同一台机器上配置并运行 + 3个节点的集群。在每个节点上都创建了一个JMS topic的订阅者(subscriber)。只在其中一个节点上 + 创建了一相发送者来向这个topic发送一些消息。然后我们确认所有的subscriber都接收到了这些消息。 +
+
+ 集群的Topic + clustered-topic例子将一个JMS topic部署到两个节点上。这两个节点组成一个集群。 + 然后在每个节点上创建了一个订阅者(subscriber),只在一个节点上创建一个发送者(producer)。通过这个发 + 送者发送一些消息,确认两个订阅者都收到了这些消息。 +
+
+ 限制接收速率 + HornetQ可以控制一个JMS消息接收者接收消息的速度。这是在创建或部署连接工厂时通过其配置参数来完成的。 + 如果设置了这个速度的限制,HornetQ会保证其向接收者传递消息的速度永远不会超过这个限制。 +
+
+ 死消息(Dead Letter) + dead-letter例子让你了解如何定义和处理死消息。有时候消息由于某种原因不能成功 + 地传递出去,比如接收者在接收消息的交易中发生回滚。 + 发生回滚后,消息被”退回“到JMS目标(destination)准备进行重发。这一过程可能会被不停地重复下去造成 + 消息永远发不出去,而且浪费系统的时间。 + 为了避免上述情况的发生,消息系统引入了死消息的概念:即当一个消息被反复重发不成功达到一定的次数时,该消息 + 便成为了死消息,它将从所属目标(destination)中删除并发送到一个称为死消息目标的目标。用户可以从死消息目标 +          上接收这些死消息以便进行分析。 +
+
+ 延迟再发送 + delayed-redelivery是一个展示如何配置HornetQ延迟再发送消息的例子。 + 当客户端经常发生故障或发生事务回滚时,消息会不停地重复发送,这样会造成CPU和网络资源被不间断的 + 重复发送所占用,影响其它工作的进行。延迟再发送可以有效地减轻这种情况。 +
+
+ 转移(Divert) + HornetQ通过配置可以将消息从一个地址自动地转移到另一地址。这个例子就是向用户展示转移的配置和使用。 +
+
+ 持久订阅(Durable Subscription) + durable-subscription是一个在HornetQ中如何使用持久订阅(durable + subscription)的例子。持久订阅是标准JMS的一部分,在JMS 1.1规范中有它的详细定义。 + 对于一个持久订阅来说,它的消息可以在订阅没有处于接收状态时被保留。另外,如果发到它的消息是持久 + 消息的话,这些消息可以在服务器故障或重启时不丢失。 +
+
+ 嵌入方式(Embedded) + embedded是一个如何将HornetQ服务嵌入到你的应用中的例子。 +
+
+ HTTP 传输协议的支持 + http-transport展示了HornetQ如何支持在传输层使用HTTP协议来发送和接收消息。 +
+
+ 直接实例化JMS对象 + JMS 对象是指 连接工厂(ConnectionFactory)队列(Queue)话题(Topic) 的实例。通常情况下它们通过JNDI服务 + 来获取。它们在JMS术语中被称为“被管理的对象(administered objects)”。 + 有的时候客户端没有JNDI服务可用,或者不适合使用JNDI。那么在没有JNDI的情况下HornetQ允许直接在客户端 + 将这些JMS对象实例化。 +
+
+ 拦截器(Interceptor) + HornetQ可以配置拦截器以便用户可以自己处理各种各样的消息事件。这个例子就是给用户展示如何使用 + 拦截器。 +
+
+ JAAS + jaas是一个如何配置JAAS安全模式的例子。HornetQ可以使用JAAS来进行用户的验证与权限控制。 +
+
+ JMS桥(Bridge) + jms-brige是一个在两个单独HornetQ服务器之间设置桥的例子。 +
+
+ JMX管理 + jmx例子展示了如何使用JMX来管理HornetQ。 +
+
+ 大消息 + large-message例子给用户展示了使用HornetQ来发送和接收大消息的功能。HornetQ + 支持超大消息的发送与接收。这些消息可以大到内存无法装下。它的大小只受服务器的硬盘空间的限制。 + 在服务器端大消息是被持久化的,所以它可以承受服务器的崩溃或重启而不丢失或损坏。 +
+
+ 最新值队列 + last-value-queue向用户展示了如何定义与使用最新值队列。当在配置文件定义好 + 最新值的参数后,这些最新值队列就会自动地用新的消息取代旧的消息,也就是说旧的消息被抛弃掉。这样一个最新 + 值的队列总是保留最新的消息在队列中。 + 股票价格消息就是一个典型的最新值队列的用例。对用户来说他所关心的是一支股票的最新价格,对于过去的价格 + 是没有多大兴趣的。 +
+
+ 分布式队列的负载均衡 + clustered-queue例子中配置了一个2节点的HornetQ服务集群。在集群上部署了 + 一个分布式JMS队列。 + 然后在一个节点上创建了一个发送者(producer),在两个节点上分别创建一个接收者(consumer)。通过 + 发送者向队列发送一些消息然后被两的接收者以轮流(round-robin)的方式接收。 + 本例说明了HornetQ可以将消息向集群中的每个接收者分布式地传递消息。 +
+
+ 管理 + management例子展示的是如何使用JMS消息来实现对HornetQ的管理。 +
+
+ 管理通知 + management-notification展示了HornetQ如何以JMS消息的形式向用户发送 + 管理通知。当某些事件发生时(如接收都创建,关闭;地址创建与删除;安全验证失败等等),HornetQ会向客户 + 发出JMS消息以通知客户这些事件的相关信息。客户接收到这些信息后可以作出相应的处理。 +
+
+ 消息计数器 + message-counters是一个展示如何使用消息计数器获取JMS队列中的消息信息。 +
+
+ 消息失效 + expiry例子中包括了如何定义和使用消息失效期。消息如果在消息服务器中存留超过一定 + 的时间,就可以被删除。根据JMS规范,接收者就不应该接收到已经过了失效期的消息。(但是并不保证一定接收不到)。 + HornetQ可以给一个队列配上一个失效地址,当队列中的消息失效时,它们就会从队列中删除并转移到该失效地址。 + 这些“失效"的消息可以从失效地址中接收并进行分析。 +
+
+ 消息组 + message-group展示的是如何在HornetQ中配置消息组。消息组可以让你的消息 + 只被一个接收者接收。属于一个消息组中的消息有如下特性: + + + + 同一个消息组中的消息都有相同的组ID。即它们的JMSXGroupID属性值相同。 + + + 第一个接收到消息组中的消息的接收者将会接收到所有该组中的消息。 + + + +
+
+ 消息组(例2) + message-group2是另外一个消息组的例子。它展示的是通过配置连接工厂来实现 + 消息组的功能。 +
+
+ 消息优先级 + 消息优先级会影响消息的传递顺序。 + 消息优先级由标准的JMS消息头属性JMSPriority的值确定。参见JMS 1.1规范。 + 优先级是一个0到9之间的整数值。当消息被传递时,根据优先级的不同消息的传递顺序会收到影响。优先级 + 高的消息往往会比优先级低的先传递给接收者。 + 优先级相同的消息会按照它们到达目标的顺序来传递。在JMS 1.1规范中有详细的规定。 +
+
+ 零接收缓冲 + 默认时HornetQ的接收者客户端有一个消息缓冲,它用来保存从服务器上预先接收的消息。这样做是为了提高 + 性能。因为如果没有这个缓冲,每次调用receive()或onMessage()后,HornetQ就会访问一次服务器请求下 + 一个消息。 + 这样每接收一个消息就会增加一次网络往返的传输。因此,HornetQ在默认情况下使用客户端的接收缓冲来 + 预先接收消息,以提高效率。 + 然而在某些情况下这样的缓冲不符合应用需要。那么可以将缓冲关闭。本例就是展示如何关闭接收缓冲。 +
+
+ 带有服务器数据复制的非事务失效备援 + non-transaction-failover例子展示了由两个服务器组成的高可获得性主/从关系。 + 客户端使用一个非交易的JMS会话(session)可以在主节点崩溃的情况下从主节点失效备援到备份节点。 + HornetQ的这一功能是通过主、备节点间的状态复制来实现的。当主节点发生故障崩溃时,客户端的连接可以自动 + 转向备份节点以继续的发送或接收消息。当使用非事务性的会话时,有可能发生消息丢失或重复传递的情况。 +
+
+ 分页(paging) + paging例子展示了HornetQ在内存有限时如何支持超大容量的队列。当内存不够时, + HornetQ会将消息保存到磁盘上;需要时再将它们从磁盘读入内存。这一过程对用户是透明的。 +
+
+ 预先通知 + 标准的JMS支持3种通知模式: + AUTO_ACKNOWLEDGE(自动通知)、CLIENT_ACKNOWLEDGE客户通知以及 DUPS_OK_ACKNOWLEDGE可重复通知。请参阅JMS规范和教程来进一步了解这几种通知方式。 + 所有方式都需要从客户端发通知到服务器端。有时当发生故障时你并不在乎丢失一些消息,这样可以采用在服务器端在消息 + 传递前进行通知就显得比较合理。本例就是展示如何使用这一HornetQ独有的通知方式。 +
+
+ 消息发送速度限制 + producer-rte-limit例子展示了如何设置HornetQ的最大消息发送速率。它控制消息的 + 发送者(JMS producer)发送消息的最大速度。 +
+
+ 队列 + 这一个简单的JMS队列的例子。 +
+
+ Message再分配 + queue-message-redistribution例子展示了如何将消息在集群的各节点同名的队列 + 间进行再分配。 +
+
+ 队列请求 + 这是一个简单的实现队列请求的例子。 +
+
+ 带消息选择器(selector)的队列 + queue-selector例子展示了如何使用选择器来有条件地选择消息进行接收。 +
+
+ 节点连接重试 + reattach-node例子展示了如何使客户端在发生故障时重试连接到原有服务器,而不是 + 直接放弃并通知用户的ExceptionListener。通过配置,客户端可以自动的不断重试连接直到服务器连接上为止。 +
+
+ 请求/应答 + 一个简单的展示JMS 请求/应答消息方式的例子。 +
+
+ 定时消息 + scheduled-message例子展示了如何向HornetQ发送定时消息(scheduled message)。 + 所谓定时消息就是在规定的将来的某一时间传递的消息。 +
+
+ 安全 + security例子展示了如何配置HornetQ的安全参数。 +
+
+ 发送通知 + send-acknowledgements例子展示了如何使用HornetQ提供的高级异步发送通知功能 + (asynchronous send acknowledgements)。这是服务器向客户端通知消息已经 + 被接收。 +
+
+ SSL传输支持 + ssl-enabled例子展示了如何配置使用SSL来发送与接收消息。 +
+
+ 静态消息选择器 + static-selector例子展示了如何配置HornetQ核心队列的静态消息选择器(又称过滤器)。 +
+
+ 使用JMS方法来配置静态消息选择器 + static-selector-jms例子采用JMS方法来配置HornetQ的队列的静态选择器(过滤器)。 +
+
+ Stomp + stomp例子展示了如何配置HornetQ来发送与接收Stomp消息。 +
+
+ Stomp与Web Sockets + stomp-websockets例子给出了如何配置一个HornetQ服务器直接从Web浏览器 + 中(需要支持Web Socket)发送和接收Stomp消息。 +
+
+ 对称型集群 + symmetric-cluster例子展示如何设置一个HornetQ的对称型集群。 + HornetQ的集群配置是非常灵活的。你可以根据需要设置不同的集群结构。最常用的就是对称型的集群了。这是在应用 + 服务器中常见的集群类型。 + 对称型的集群具有同一性,即每个节点与其他节点处于同等地位,并且每一个节点都与其他任一节点相连接。 +
+
+ 临时队列 + 本例展示的是如何使用一个JMS临时队列(temporary queue)。 +
+
+ 话题(Topic) + 一个简单的JMS topic的例子。 +
+
+ 话题体系(Topic Hierarchy) + HornetQ支持话题体系。所谓话题体系就是允许你使用通配符来注册一个订阅(subscriber),这样所有发送到 + 与该通配符相匹配的地址的消息都可以被该订阅收到。 +
+
+ 话题选择器例1 + topic-selector-example1例子展示的是如何创建带有选择器的JMS话题(Topic)订阅。 +
+
+ 话题选择器例2 + topic-selector-example2 是另一个使用带有选择器的JMS话题(Topic)订阅的例子。 +
+
+ 带有数据复制的事务性失效备援 + transaction-failover例子展示了由两个服务器组成的高可获得性主/备关系。 + 客户端使用一个交易的JMS会话(session)可以在主节点崩溃的情况下从主节点失效备援到备份节点。 + HornetQ的这一功能是通过主、备节点间的状态复制来实现的。当主节点发生故障崩溃时,客户端的连接可以自动 + 转向备份节点以继续的发送或接收消息。当使用事务性的会话时,能够保证消息被传递并且只被传递一次。 +
+
+ 事务性会话 + transactional例子展示了如何在HornetQ中使用事务性会话。 +
+
+ XA Heuristic + xa-heuristic例子给出了如何通过HornetQ的管理接口来做出一个XA的heuristic决定。 + 一个XA的heuristic决定是一个单方面的对一个已经准备的(prepared)XA事务分支提交或回滚的决定。 +
+
+ XA 接收 + xa-receive例子展示的是如何使用HornetQ在一个XA事务内接收消息。 +
+
+ XA 发送 + xa-send例子展示的是如何使用HornetQ在一个XA事务内发送消息。 +
+
+ XA与事务管理器(transaction manager) + xa-with-jta展示了如何在HornetQ中使用JTA接口来控制事务。 +
+
+
+ 核心API的例子 + 运行核心API的例子很简单,只要进到相应的例子目录下运行“ant"即可。 +
+ 嵌入式 + 本例展示了如何将HornetQ服务器嵌入到你的代码中。 +
+
+
+ Java EE 例子 + 绝大多数的Java EE例子都可以按如下步骤运行:进入到相应的目录中,先运行ant deploy。 + 这一步创建了一个新的JBoss的服务器配置方案并启动它。当JBoss服务器启动后,再运行ant run + 启动例子程序。有些例子需要额外的步骤,请参见相关的例子的文档。 +
+ EJB/JMS 事务 + 这个例子展示了在一个事务内使用EJB和JMS的方法。 +
+
+ HAJNDI (High Availability) + 这个例子展示了如何使用集群中的JNDI服务。 +
+
+ 资源适配器的配置(JCA) + 本例展示了如何配置HornetQ的JCA适配器的各种参数。 +
+
+ 资源适配器运程服务器的配置 + 本例展示了如何配置HornetQ的JCA适配器来与远程的HornetQ服务器通迅。 +
+
+ JMS 桥(Bridge) + 本例展示了如何使用HornetQ的JMS bridge。 +
+
+ MDB (消息驱动Bean) + 一个消息驱动bean的例子。 +
+
+ Servlet传输 + 一个展示在HornetQ中使用servlet作为传输层的例子。 +
+
+ Servlet SSL 传输 + 一个展示在HornetQ中使用基于SSL之上的servlet传输的例子。 +
+
+ XA 恢复(recovery) + 这是一个展示HornetQ在JBoss应用服务器中的XA recovery是如何工作的例子。 +
+
+
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/filter-expressions.xml ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/filter-expressions.xml b/docs/user-manual/zh/filter-expressions.xml new file mode 100644 index 0000000..8a3e560 --- /dev/null +++ b/docs/user-manual/zh/filter-expressions.xml @@ -0,0 +1,71 @@ + + + + + + + + + + + + + + + + + + + + + + 过滤器表达式 + HornetQ提供了一套强大的过滤器(filter)语言。它的语法是基于SQL 92表达式的部分语法。 + 实际上它与JMS选择器(selector)的语法是相同的。只是其中有一些预定义的标识符有所不同。有关 + JMS选择器的相关知识参见 javax.jms.Message + HornetQ在以下以个地方使用了过滤器表达式: + + + 预定义的队列。当在hornetq-configuration.xmlhornetq-jms.xml定义 + 队列时,可以使用过滤器。只有与过滤器表达式相匹配的消息才能达到该队列中。 + + + 核心桥可以使用可选的过滤器表达式。只有与表达式相匹配的消息才被桥处理。 + 参见()。 + + + 转移(Divert)也可以使用可选的过滤器表达式。只有与表达式匹配的消息才被转移。 + 参见()。 + + + 另外过滤器还可以在编程方式创建接收者(consumer)和队列时使用。还有一些应用过滤器的地方在 + 中有所描述。 + + + HornetQ的内核过滤器表达式与JMS选择器表达式是有所不同的。JMS选择器应用于JMS消息,而HornetQ的内核过滤 + 器表达式则用于内核消息。 + 以下标识符可以用在内核消息的过滤器表达式中,用来引用内核消息的属性: + + + HQPriority。代表消息的优先级。消息优先级属性的有效值为0到9间的整数。 + 0为最低优先级,9为最高优先级。例:HQPriority = 3 AND animal = 'aardvark' + + + HQExpiration。代表消息的失效时间。其值为一长整形数。 + + + HQDurable。代表消息是否是持久消息。它是一个字符型的属性,有效值为 DURABLE + 或 NON_DURABLE + + + HQTimestamp。代表消息的创建时间,其值为一长整形数。 + + + HQSize。消息的大小。单位为字节。其值是一个整形数。 + + + 任何其它的标识符在内核过滤器的表达式中都认为是代表着该消息的一个属性。 + http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/flow-control.xml ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/flow-control.xml b/docs/user-manual/zh/flow-control.xml new file mode 100644 index 0000000..c1e041e --- /dev/null +++ b/docs/user-manual/zh/flow-control.xml @@ -0,0 +1,243 @@ + + + + + + + + + + + + + + + + + + + + 流控制 + 流控制是指对客户端与服务器之间,或者服务器之间的数据流量进行限制,目的是防止通迅双方由于大量数据而过载。 +
+ 接收者(consumer)流控制 + 这是指对客户端的接收者接收消息流的控制。通常为了提高效率,在客户端通常将消息放入缓存,然后再将缓存中 + 的消息传递给接收者(consumer)。当接收者处理消息的速度小于服务器向其发送消息的速度时,就可能造成消息在 + 客户端不断积累,最終引起内存溢出的错误。 +
+ 基于窗口的流控制 + 默认情况下HornetQ的接收者一端会将消息进行缓存以提高性能。如果不这样做,那每次接收者收到一个消息, + 都得通知服务器传递下一个消息,然后服务器再将下一个消息传递过来。这就增加了通信的次数。 + 对于每一次消息传递都有一个网络的往返通信,这样降低了性能。 + 为了避免这样,HornetQ将每个接收者的消息提前接收到一处缓存中。每个缓存的最大值由 + consumer-window-size参数决定(单位字节)。 + consumer-window-size的默认值是 1 MiB (1024 * 1024 + 字节)。 + 它的值可以是: + + + -1 代表大小无限制的缓存。 + + + 0 代表不缓存消息。参见相关的例子 + + + >0 代表缓存的最大字节数。 + + + 合理设置接收者的窗口大小可以显著提高性能。下面是两个极端的例子: + + + 快速接收者 + + 所谓快速接收者是指消息的接收者处理消息的速度大于等于它的接收速度。 + 对于快速接收者或以将consumer-window-size设为 + -1,使得客户端的消息缓存的大小 无限制 + 请谨慎使用这一设置值: 如果接收者的消息处理速度比接收速度小,可造成客户端内存溢出。 + + + + 慢接收者 + + 所谓慢接收者是指接收者每处理一个消息就要花很多时间。这样将缓存关闭就比较合理。服务器可以将多余的 + 消息传递给其它的接收者。 + 假设一个队列有2个接收者。其中一个接收者非常慢。消息被轮流传递到两个接收者。其中的快速接收者 + 很快将其缓存中的消息处理完毕。同时慢接收者的缓存中还有一些消息等待处理。这样快速接收者在一段时间 + 内就处于空闲状态。 + 这时,将consumer-window-size 设为0 (没有缓存),就可以将它变成 + 慢接收者。这样在慢接收者一方不会缓存消息,这使得快的接收者可以处理更多的消息,而不至于处于空闲 + 状态。 + 这说明将它设置为0可以控制一个队列的消息在多个接收者之间的消息分配。 + + + + 大多数情况下很难判断哪些接收者是快速的,哪些是慢速的。往往很多接收者是处于两者之间。这样对于 + consumer-window-size的值就要视具体情况而定。有时需要进行一定的测试 + 来决定它的最佳值。通常情况下将其设为1MiB可以满足大多数的应用情况。 +
+ 使用核心接口(Core API)进行流控制 + Hornet的核心接口中,ClientSessionFactory.setConsumerWindowSize()方法和一些 + ClientSession.createConsumer()方法可以控制流的窗口大小。 +
+
+ 使用JMS的流控制 + 若使用JNDI来获得连接工厂,则需要通过配置hornetq-jms.xml文件来设定窗口大小: + +<connection-factory name="ConnectionFactory"> + <connectors> + <connector-ref connector-name="netty-connector"/> + </connectors> + <entries> + <entry name="ConnectionFactory"/> + </entries> + + <!-- Set the consumer window size to 0 to have *no* buffer on the client side --> + <consumer-window-size>0</consumer-window-size> +</connection-factory> + + 如果直接实例化连接工厂,则使用HornetQConnectionFactory.setConsumerWindowSize() + 方法来设定窗口大小。 + 参见例子来了解如何配置HornetQ来 + 关闭接收者的缓存。 +
+
+
+ 速率流控制 + 我们还可以通过控制 速率的方法来控制流。这是一种像调节节流阀的形式。 + 这种方法保证一个接收者接收消息的速率不会超过设定的值。 + 速率必须是一个正整数。它代表最大接收速度,单位是消息每秒。将它设为-1就会关闭速率流控制。 + 默认值是-1 + 参见有关速率流控制的例子以进一步了解它的工作原理。 +
+ 使用核心接口(Core API) + HornetQ的核心接口的ClientSessionFactory.setConsumerMaxRate(int consumerMaxRate)方法或 + 某些ClientSession.createConsumer()方法可以实现对流的速率控制。 +
+
+ 使用JMS + 如果从JNDI中获取连接工厂,需要通过配置hornetq-jms.xml来进行速率流控制: + <connection-factory name="ConnectionFactory"> + <connectors> + <connector-ref connector-name="netty-connector"/> + </connectors> + <entries> + <entry name="ConnectionFactory"/> + </entries> + <!-- We limit consumers created on this connection factory to consume messages + at a maximum rate + of 10 messages per sec --> + <consumer-max-rate>10</consumer-max-rate> + </connection-factory> + 如果是直接实例化连接工厂,则通过HornetQConnectionFactory.setConsumerMaxRate(int + consumerMaxRate)方法来设定最大流速率。 + + 速率流控制可以与窗口流控制结合使用。速率控制只规定了客户端每秒接收多少消息。因此如果你设定 + 了一个较低的速率,同时又设定了一个大的缓存窗口,那么客户端的缓存将会很快饱和。 + + 参见接收速率流控制的例子进一步了解速率流控制的配置和使用。 +
+
+
+
+ 发送者(producer)的流控制 + HornetQ还可以控制客户端向服务器发送消息的速度,以避免服务器因大量数据过载。 +
+ 基于窗口的流控制 + 与接收者的相应的控制相似。在默认条件下,发送者要有足够的份额(credits)才可以向服务器的地址发送消息。 + 这个份额就是消息的大小。 + 当发送者的份额不足时,它要向服务器请求更多的份额以便发送更多的消息。 + 发送者一次向服务器请求的份额值被称为窗口大小 + 于是窗口大小就是指发送者向服务器不间断发送消息的总最大字节数。当发送完毕时需再向服务器请求份额。这样就避免了 + 服务器消息过载的情况。 +
+ 使用核心接口(Core API) + 若使用核心接口,ClientSessionFactory.setProducerWindowSize(int producerWindowSize) + 方法可以对窗口大小进行设定。 +
+
+ 使用JMS + 如果使用JNDI来获得连接工厂,则需要配置hornetq-jms.xml文件以设定窗口大小: + + <connection-factory name="ConnectionFactory"> + <connectors> + <connector-ref connector-name="netty-connector"/> + </connectors> + <entries> + <entry name="ConnectionFactory"/> + </entries> + <producer-window-size>10</producer-window-size> + </connection-factory> + 如果是直接实例化连接工厂,则使用HornetQConnectionFactory.setProducerWindowSize(int + producerWindowSize)方法来设定窗口大小。 +
+
+ 限定发送者窗口流控制 + 通常情况下客户端请求多少份额,HornetQ服务器就给予多少份额。然而我们还可以针对每个地址来设定一个最大 + 的份额值,以使服务器给出的份额都不大于该值。这样可以防止一个地址的内存溢出。 + 例如,如果有一个队列称为“myqueue”。将它的最大内存值设为10MiB,则服务器就会控制给出的份额以保证向该队列的地 + 址发送消息时不会占大于10MiB的内存空间。 + 当一相地址已经满了的时候,发送者将会阻塞直到该地址有了多余的空间为止,即地址中的消息被接收了一部分后使得 + 地址腾出了一些空间。 + 我们将这种控制方法称为限定发送者窗口流控制。这是一种有效的防止服务器内存溢出的手段。 + 它可以看成是分页转存(paging)的另一种方法。分页转存不阻塞发送者,它将消息转存到存贮介质上以节省内存的空间。 + 要配置一个地址的最大容量并告诉服务器在地址满了的情况下阻塞发送者,你需要为该地址定义一个 + AddressSettings () 并设定 + max-size-bytesaddress-full-policy + 这个配置对所有注册到该地址的队列有效。即所有注册队列的总内存将不超过 max-size-bytes。对于JMS topic情况则意谓着该topic的所有订阅的内存不能超过 + max-size-bytes的设定值。 + 下面是一个例子: + + <address-settings> + <address-setting match="jms.queue.exampleQueue"> + <max-size-bytes>100000</max-size-bytes> + <address-full-policy>BLOCK</address-full-policy> + </address-setting> + </address-settings> + 上面的例子将JMS队列"exampleQueue"的最大内存值设为 + 100000 字节并且阻塞发送者以防止消息量超过这个值。 + 注意必须设置 BLOCK的策略才能打开限定发送者窗口控制。 + 请注意默认的配置下当一个地址中的消息量达到10MiB时,其所有的消息发送者将变为阻塞状态,也就是说 + 在没有接收的情况下你不能向一个地址不阻塞地一次发送超过10MiB的消息。要想增加这个限制,可以加大 + max-size-bytes参数的值,或者调整地址的消息容量限制。 + +
+
+
+ 速率流控制 + HornetQ也可以控制发送者发送消息的速率。单位是每秒消息数。通过设定速率可保证发送者的发送速率不超过某个值。 + 速率必须是一个正整数。如果设为 -1 则关闭速率流控制。默认值是-1 + 请参见例子进一步了解速率流控制的使用方法。 +
+ 使用核心接口(Core API) + 如果使用核心接口,ClientSessionFactory.setProducerMaxRate(int consumerMaxRate)方法或 + 某些 ClientSession.createProducer()方法可以设置最大速率值。 +
+
+ 使用 JMS + 如果使用JNDI,需要配置hornetq-jms.xml文件: + <connection-factory name="ConnectionFactory"> + <connectors> + <connector-ref connector-name="netty-connector"/> + </connectors> + <entries> + <entry name="ConnectionFactory"/> + </entries> + <!-- We limit producers created on this connection factory to produce messages + at a maximum rate + of 10 messages per sec --> + <producer-max-rate>10</producer-max-rate> + </connection-factory> + 如果直接实例化连接工厂,则使用HornetQConnectionFactory.setProducerMaxRate(int + consumerMaxRate)方法来设置。 +
+
+
+
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/ha.xml ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/ha.xml b/docs/user-manual/zh/ha.xml new file mode 100644 index 0000000..1977dfe --- /dev/null +++ b/docs/user-manual/zh/ha.xml @@ -0,0 +1,283 @@ + + + + + + + + + + + + + + + + + + + + 高可获得性(High Availability)和失效备援(Failover) + 高可获得性是指当系统中有一台甚至多台服务器发生故障时还能继续运转的能力 + 作为高可获得性的一部分,失效备援的含意是 + 当客户端当前连接的服务器发故障时,客户端可以将连接转到另一台正常的服务器,从而能够继续工作 +
+ 主要-备份对 + HornetQ可以将两个服务器以主要-备份对的形式连接在一起。目前HornetQ允许一个 + 主要服务器有一个备份服务器,一个备份服务器只有一个主要服务器。在正常情况下主要服务器工作,备份服务器只有当 + 发生失效备援发生时工作。 + 没有发生失效备援时,主要服务器为客户端提供服务,备份服务器处于待机状态。当客户端在失效备援后连接到备份服务 + 器时,备份服务器开始激活并开始工作。 +
+ 高可获得性(HA)的模式 + HornetQ的高可获得性有两种模式:一种模式通过由主服务器日志向备份服务器日志 + 复制数据。另一种模式则是主服务器与备份服务器间存贮共享 + + 只有持久消息才可以在失效备援时不丢失。所有非持久消息则会丢失。 + +
+ 数据复制 + 在这种模式下,保存在HornetQ主服务器中日志中的数据被复制到备份服务器日志中。注意我们并不复制 + 服务器的全部状态,而是只复制日志和其它的持久性质的操作。 + 复制的操作是异步进行的。数据通过流的方式复制,复制的結果则通过另一个流来返回。通过这样的异步方式 + 我们可以获得比同步方式更大的呑吐量。 + 当用户得到确认信息如一个事务已经提交、准备或加滚,或者是一个持久消息被发送时,HornetQ确保这些状态 + 已经复制到备份服务器上并被持久化。 + 数据复制这种方式不可避免地影响性能,但是另一方面它不依赖于昂贵的文件共享设备(如SAN)。它实际上是 + 一种无共享的HA方式。 + 采用数据复制的失效备援比采用共享存储的失效备援要快,这是因为备份服务器在失效备援时不用重新装载日志。 + +
+ 配置 + 首先在主服务器的 hornetq-configuration.xml文件中配置备份服务器。 + 配置的参数是backup-connector-ref。这个参数指向一个连接器。这个连接器 + 也在主服务器上配置。它定义了如何与备份服务器建立连接。 + 下面就是一个在hornetq-configuration.xml文件中的例子: + + <backup-connector-ref connector-name="backup-connector"/> + + <connectors> + <!-- 这个连接器用于连接备份服务喝咖啡 --> + <!-- 备份服务器在主机"192.168.0.11"上,端口"5445" --> + <connector name="backup-connector"> + <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class> + <param key="host" value="192.168.0.11"/> + <param key="port" value="5445"/> + </connector> + </connectors> + 其次在备份服务器上,我们设置了备份服务器的标志,并且配置了相应的接受器以便主服务器能够建立 + 连接。同时我们将shared-store参数设为false。 + + <backup>true</backup> + + <shared-store>false<shared-store> + + <acceptors> + <acceptor name="acceptor"> + <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class> + <param key="host" value="192.168.0.11"/> + <param key="port" value="5445"/> + </acceptor> + </acceptors> + + 为了使备份服务器正常工作,一定要保证它与主服务器有着同样的桥、预定义的队列、集群连接、 + 广播组和发现组。最简单的作法是拷贝主服务器的全部配置然后再进行上述的修改。 +
+
+ 备份服务器与主服务器间的同步 + 为了能正常工作,备份服务器与主服务器必须同步。这意谓着备份服务器不能是当前任意一个备份服 + 务器。如果你这样做,主服务器将不能成功启动,在日志中会出现异常。 + 要想将一个现有的服务器配置成一个备份服务器,你需要将主服务器的data + 文件夹拷贝到并覆盖这个备份 + 服务器的相同文件夹,这样做保证了备份服务器与主服务器的持久化数据完全一致。 + 当失效备援发生后,备份服务器代替主服务器工作,原来的主服务器失效。这时简单的重启主服务 + 器是不行的。要想将主服务器与备份重新进行同步,就必须先将主服务器和备份服务器同时停止,再将 + 主服务器的数据拷贝到备份服务器,然后再启动。 + HornetQ以后将支持备份与主服务器间的自动同步,无需停止主服务器。 +
+
+
+ 存贮共享 + 使用存贮共享,主服务器与备份服务器共用相同目录的日志数据,通常是一个共享的 + 文件系统。这包括转存目录,日志目录,大消息及绑定日志。 + 当发生失效备援时,工作由备份服务器接管。它首先从共享的文件系统中读取主服务器的持久数据,然后 + 才能接受客户端的连接请求。 + 与数据复制方式不同的是这种方式需要一个共享的文件系统,主服务器与备份服务器都可以访问。典型的 + 高性能的共享系统是存贮区域网络(SAN)系统。我们不建议使用网络附加存贮(NAS),如NFS,来存贮共享 + 日志(主要的原因是它们比较慢)。 + 共享存贮的优点是不需要在主服务器与备份服务器之间进行数据复制,因此对性能不会造成影响。 + 共享存贮的缺点是它需要一个共享文件系统。同时,当备份服务器激活时它需要首先从共享日志中读取相应 + 的信息,从而占用一定的时间。 + 如果你需要在一般工作情况下保持高性能,并且拥有一个快速的SAN系统,同时能够容忍较慢的失效备援 + 过程(取决于数据量在多少),我们建议你采用存贮共享方式的高可获得性。 + +
+ 配置 + 要使用存贮共享模式,在两个服务器的配置文件hornetq-configuration.xml + 中将作如下设置: + + <shared-store>true<shared-store> + + 此外,备份服务器必须显式地指定: + + <backup>true</backup> + + 另外,需要将主服务器和备份服务器的日志文件位置指向同一个共享位置。 + (参见 + 如果客户端使用JMS自动失效备援,主服务器除了要配置一个连接器以连接到备份服务器外,还要在 + 配置文件hornetq-jms.xml中指向这个连接器,如 + 中所解释的那样。 +
+
+ 备份服务器与主服务器间的同步。 + 由于主备服务器之间共享存贮,所以它们不需要进行同步。但是它需要主备服务器同时工作以提供 + 高可获得性。如果一量发生失效备援后,就需要在尽可能早的时间内将备份服务器(处于工作状态)停下来, + 然后再启动主服务器和备份服务器。 + HornetQ以后将支持自动同步功能,不需要先停止服务器。 +
+
+
+
+
+ 失效备援的模式 + HornetQ定义了两种客户端的失效备援: + + + 自动客户端失效备援 + + + 应用层的客户端失效备援 + + + HornetQ还支持100%透明的同一个服务器的自动连接恢复(适用于网络的临时性故障)。这与失效备援很相似, + 只不过连接的是同一个服务器,参见 + 在发生失效备援时,如果客户端有非持久或临时队列的接收者时,这些队列会自动在备份服务器上重新创建。对于 + 非持久性的队列,备份服务器事先是没有它们的信息的。 +
+ 自动客户端失效备援 + HornetQ的客户端可以配置主/备份服务器的信息,当客户端与主服务器的连接发生故障时,可以自动检测到故障并 + 进行失效备援处理,让客户端连接到备份服务器上。备份服务器可以自动重新创建所有在失效备援之前存在的会话与接收 + 者。客户端不需要进行人工的连接恢复工作,从而节省了客户端的开发工作。 + HornetQ的客户端在参数client-failure-check-period(在 + 中进行了解释)规定的时间内如果没有收到数据包,则认为连接发生故障。 + 当客户端认为连接故障时,它就会尝试进行失效备援。 + HornetQ有几种方法来为客户端配置主/备服务器对的列表。可以采用显式指定的方法,或者采用更为常用的 + 服务器发现的方法。有关如何配置服务器发现的详细信息,请参见 + 。 + 关于如何显式指定主/备服务器对的方法,请参见中的解释。 + 要使客户端具备自动失效备援,在客户端的配置中必须要指定重试的次数要大于零(参见 + 中的解释)。 + 有时你需要在主服务器正常关机的情况下仍然进行失效备援。如果使用JMS,你需要将HornetQConnectionFactoryFailoverOnServerShutdown属性设为true,或者是在hornetq-jms.xml(参数为failover-on-server-shutdown)文件中进行相应的配置。如果使用的是核心接口,可以在创建 + ClientSessionFactoryImpl实例时将上述同名属性设置为true。 + 这个属性的默认值是false。这表示如果主服务器是正常关机,客户端将不会进行失效备援 + + + 默认正常关机不会不会导致失效备援。 + 使用CTRL-C来关闭HornetQ服务器或JBoss应用服务器属于正常关机,所以不会触发客户端的失效 + 备援。 + 要想在这种情况下进行失效备援必须将属性FailoverOnServerShutdown + 设为true。 + + + 默认情况下至少创建了一个与主服务器的连接后失效备援才会发生。换句话说,如果客户端每一次创建与 + 主服务器的连接失败,它会根据参数reconnection-attempts的设置进行连接重试,而不是进行失效备援。 + 如果重试次数超过的该参数的值,则连接失败。 + 在有些情况下,你可能希望在初始连接失败和情况下自动连接到备份服务器,那么你可以直接在 + ClientSessionFactoryImplHornetQConnectionFactory上设置FailoverOnInitialConnection + 参数,或者在配置文件中设置failover-on-initial-connection。默认的值是false + 有关事务性及非事务性JMS会话的自动失效备援的例子,请参见 + +
+ 关于服务器的复制 + HornetQ在主服务器向备份服务器复制时,并不复制服务器的全部状态。所以当一个会话在备份服务器 + 中重新创建后,它并不知道发送过的消息或通知过的消息。在失效备援的过程中发生的消息发送或通知也可 + 能丢失。 + 理论上如果进行全部状态的复制,我们可以提供100%的透明的失效备援,不会失去任何的消息或通知。 + 但是这样做要付出很大的代价:即所有信息都要进行复制(包括队列,会话等等)。也就是要求复制服务 + 器的每个状态信息,主服务器的每一步操作都将向其备份进行复制,并且要在全局内保持顺序的一致。这样 + 做就极难保证高性能和可扩展性,特别是考虑到多线程同时改变主服务器的状态的情况,要进行全状态复制 + 就更加困难。 + 一些技术可以用来实现全状态复制,如虚拟同步技术 + (virtual synchrony)。但是这些技术往往没有很好的可扩展性,并且将所有操作都 + 进行序列化,由单一线程进行处理,这样明显地将底了并行处理能力。 + 另外还有其它一些多线程主动复制技术,比如复制锁状态或复制线程调度等。这些技术使用Java语言非常 + 难于实现。 + 因此得出结论,采用大量牺牲性能来换取100%透明的失效备援是得不偿失的。没有100%透明的失效 + 备援我们仍然可以轻易地保证一次且只有一次的传递。这是通过在发生故障时采用重复检测结合事务重试 + 来实现的。 +
+
+ 失效备援时阻塞调用的处理 + 如果当发生失效备援时客户端正面进行一个阻塞调用并等待服务器的返回,新创建的会话不会知道这个调用, + 因此客户端可能永远也不会得到响应,也就可能一直阻塞在那里。 + 为了防止这种情况的发生,HornetQ在失效备援时会解除所有的阻塞调用,同时抛出一个 + javax.jms.JMSException异常(如果是JMS)或HornetQException异常。异常的错误代码是HornetQException.UNBLOCKED。客户端需要自行处理这个异常,并且进行 + 必要的操作重试。 + 如果被解除阻塞的调用是commit()或者prepare(),那么这个事务会被自动地回滚,并且HornetQ + 会抛出一个javax.jms.TransactionRolledBackException(如果是JMS) + 或都是一个HornetQException,错误代码为 HornetQException.TRANSACTION_ROLLED_BACK(如果是核心接口)。 +
+
+ 事务的失效备援处理 + 如果在一个事务性会话中,在当前事务中消息已经发出或通知,则服务器在这时如果发生失效备援,它不 + 能保证发出的消息或通知没有丢失。 + 因此这个事务就会被标记为只回滚,任何尝试提交的操作都会抛出一个javax.jms.TransactionRolledBackException异常(如果是JMS),或者是一 + 个HornetQException的异常,错误代码为HornetQException.TRANSACTION_ROLLED_BACK(如果是核心接口)。 + 客户端需要自行处理这些异常,进行必要的回滚处理。注意这里不需要人工将会话进行回滚-此时它已经 + 被回滚了。用户可以通过同一个会话重试该事务操作。 + HornetQ发布包中包括了一个完整的例子来展示如何处理这种情况。参见 + + 如果是在提交过程中发生了失效备援,服务器将这个阻塞调用解除。这种情况下客户端很难确定在事故发生 + 之前事务是否在主服务器中得到了处理。 + 为了解决这个问题,客户端可以在事务中使用重复检测() + ,并且在提交的调用被解除后重新尝试事务操作。如果在失效备援前事务确实在主服务器上已经完成提交,那么 + 当事务进行重试时,重复检测功能可以保证重复发送的消息被丢弃,这样避免了消息的重复。 + + 通过处理异常和重试,适当处理被解除的阻塞调用并配合重复检测功能,HornetQ可以在故障条件下保证 + 一次并且只有一次的消息传递,没有消息丢失和消息重复。 + +
+
+ 非事务会话的失效备援处理 + 如果会话是非事务性的,那么通过它的消息或通知在故障时可能会丢失。 + 如果你在非事务会话中要保证一次并且只有一次 + 的消息传递,你需要使用重复检测功能,并适当处理被解除的阻塞调用。参见 +
+
+
+ 连接故障的通知 + JMS提供了标准的异步接收连接故障通知的机制:java.jms.ExceptionListener。 + 请参考JMS的javadoc或者其它JMS教程来进一步了解怎样使用这个接口。 + HornetQ的核心接口也提供了一个相似的接口 + org.hornet.core.client.SessionFailureListener + 任何ExceptionListener或SessionFailureListener的实例,在发生连接故障时,都会被HornetQ + 调用,不管该连接是否得到了失效备援、重新连接还是得到了恢复。 +
+
+ 应用层的失效备援 + 在某些情况下你可能不需要自动的客户端失效备援,希望自己来处理连接故障,使用自己的重新连接方案等。 + 我们把它称之为应用层失效备援,因为它是发生在应用层的程序中。 + 为了实现应用层的失效备援,你可以使用监听器(listener)的方式。如果使用的是JMS,你需要在JMS连接上 + 设置一个ExceptionListener类。这个类在连接发生故障时由HornetQ调用。在这个类 + 中你可以将旧的连接关闭,使用JNDI查找新的连接工厂并创建新的连接。这里你可以使用 + HA-JNDI + 来保证新的连接工厂来自于另一个服务器。 + 请参见。这是一个完整的应用层失效备援的例子。 + 如果你使用核心接口,则过程也是很相似的:你在核心的ClientSession实例上设置一个 + FailureListener,然后在这个类中进行相应的处理即可。 +
+
+
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/architecture1.jpg ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/architecture1.jpg b/docs/user-manual/zh/images/architecture1.jpg new file mode 100644 index 0000000..cb1161f Binary files /dev/null and b/docs/user-manual/zh/images/architecture1.jpg differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/architecture2.jpg ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/architecture2.jpg b/docs/user-manual/zh/images/architecture2.jpg new file mode 100644 index 0000000..274f578 Binary files /dev/null and b/docs/user-manual/zh/images/architecture2.jpg differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/architecture3.jpg ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/architecture3.jpg b/docs/user-manual/zh/images/architecture3.jpg new file mode 100644 index 0000000..3c1dfd5 Binary files /dev/null and b/docs/user-manual/zh/images/architecture3.jpg differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/console1.png ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/console1.png b/docs/user-manual/zh/images/console1.png new file mode 100644 index 0000000..19b6cbd Binary files /dev/null and b/docs/user-manual/zh/images/console1.png differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/ha-replicated-store.png ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/ha-replicated-store.png b/docs/user-manual/zh/images/ha-replicated-store.png new file mode 100644 index 0000000..9065dfe Binary files /dev/null and b/docs/user-manual/zh/images/ha-replicated-store.png differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/ha-shared-store.png ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/ha-shared-store.png b/docs/user-manual/zh/images/ha-shared-store.png new file mode 100644 index 0000000..0be2766 Binary files /dev/null and b/docs/user-manual/zh/images/ha-shared-store.png differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/hornetQ-banner_final.png ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/hornetQ-banner_final.png b/docs/user-manual/zh/images/hornetQ-banner_final.png new file mode 100644 index 0000000..6388dff Binary files /dev/null and b/docs/user-manual/zh/images/hornetQ-banner_final.png differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/images/hornetQ_logo_600px.png ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/images/hornetQ_logo_600px.png b/docs/user-manual/zh/images/hornetQ_logo_600px.png new file mode 100644 index 0000000..b71f4ba Binary files /dev/null and b/docs/user-manual/zh/images/hornetQ_logo_600px.png differ http://git-wip-us.apache.org/repos/asf/activemq-6/blob/8ecd255f/docs/user-manual/zh/intercepting-operations.xml ---------------------------------------------------------------------- diff --git a/docs/user-manual/zh/intercepting-operations.xml b/docs/user-manual/zh/intercepting-operations.xml new file mode 100644 index 0000000..63912e0 --- /dev/null +++ b/docs/user-manual/zh/intercepting-operations.xml @@ -0,0 +1,71 @@ + + + + + + + + + + + + + + + + + + + + + + 拦截操作 + HornetQ支持拦截器。拦截器可以拦截进入服务器的数据包。每进入服务器 + 一个数据包,拦截器就被调用一次,允许一些特殊和处理,例如对包的审计、过滤等。拦截器可以对数据包 + 进行改动。 +
+ 实现拦截器 + 拦截器必须要实现Interceptor接口 + +package org.hornetq.api.core.interceptor; + +public interface Interceptor +{ + boolean intercept(Packet packet, RemotingConnection connection) + throws HornetQException; +} + + 它的方法的返回值是很重要的: + + + 如果返回true,处理正常进行下去。 + + + 如果返回false,则处理被中断,其它的拦截器将不会被调用,数据包将不会 + 被服务器所处理。 + + +
+
+ 配置拦截器 + 拦截器的配置在hornetq-configuration.xml文件中: + +<remoting-interceptors> + <class-name>org.hornetq.jms.example.LoginInterceptor</class-name> + <class-name>org.hornetq.jms.example.AdditionalPropertyInterceptor</class-name> +</remoting-interceptors> + + 拦截器的类(以及它们依赖的类)必须要在服务器的classpath中,否则不能被正常初始化及调用。 +
+
+ 客户端拦截器 + 在客户端也可以有拦截器来拦截来自服务器的数据包。ClientSessionFactory + 的addInterceptor()方法可以用来添加拦截器。 + 同样拦截器的类(以及它们依赖的类)必须要在客户端的classpath中,否则它们不能被正常初始化及调用。 +
+
+ 例子 + 参见。这个例子中展示了如何使用拦截器向发往服务器的消息中 + 添加属性。 +
+