LCDS & BlazeDS 中 Channel 的配置选项

配置文件中配置 Channel 的代码片段：

<channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel">
    <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
    <properties>
        <polling-enabled>true</polling-enabled>
        <polling-interval-seconds>0</polling-interval-seconds>
        <wait-interval-millis>60000</wait-interval-millis>
        <max-waiting-poll-requests>100</max-waiting-poll-requests>
        <client-wait-interval-millis>
        <piggybacking-enabled>
        <login-after-disconnect>
        <flex-client-outbound-queque-processor>
        <serialization>
        <connect-timeout-seconds>
        <invalidate-session-on-disconnect>
        <add-no-cache-headers>
    </properties>
</channel-definition>

<properties> 中各项的具体含义：

• [polling-enable]  channel 配置可选项, 设置是否开启轮询，默认为 false.
• [polling-interval-seconds]  channel 配置可选项, 默认值为 3. 表示客户端收到前次服务器轮询响应开始到再次向服务器轮询这段等待时间的秒数。如该项为 0 则表示客户端一旦收到服务器回应就立即开始下次轮询，期间没有等待时间。与在 Flex 文件中设置 Channel 的 pollingInterval 属性作用相同。
• [wait-interval-millis]  endpoint 配置可选项, 默认值为 0, 表示服务器轮询响应线程在没有消息抵达时所等待时间的毫秒数。如在等待时段内有消息抵达则响应轮询传递消息，如超过等待时间则返回一个空的 acknowledgment 给客户端。考虑如下场景：客户端在时间点A向服务器发起轮询，如果此时服务器存在新消息则立即响应该次轮询，否则将等待 wait-interval-millis 指定毫秒时长。如果在等待的这段时间内如果有新消息抵达，服务器会立即中断等待将新消息传送到客户端，反之如果直到等待时间结束仍没有新消息抵达，则服务器返回一个空的 acknowledgment 给客户端。客户端收到消息（无论是有效消息还是空的 acknowledgment ）后继续下一轮的的等待（由 polling-interval-seconds 指定的时长）。 该选项必须配合设置 max-waiting-poll-requests 选项(非零值)才能生效。选项的两个特殊值是 0 和 -1 。0 表示服务器不等待消息的抵达，在没有新消息的情况下对客户端的轮询都返回空的 acknowledgment。如果设为 -1 则表示服务器的响应线程一直会等到新的消息抵达后才回馈客户端。该项的推荐值是一分钟，即60000。
• [max-waiting-poll-requests] endpoint 配置可选项，默认值 0。指定该项以设置 endpoint 中可以有多少处于等待状态的响应线程。超出部分的等待线程会返回空的 acknowledgment （如同 wait-interval-millis 被设为0）。
• [client-wait-interval-millis] channel 配置可选项，默认值为 0 。该选项仅出现在服务器的配置文件中，用于覆盖在客户端指定的[polling-interval-seconds]（通过在 Flex 文件中设置 Channel 的 pollingInterval 属性）。默认值0意味着采用[polling-interval-seconds]的设定。
• [piggybacking-enabled] The piggybacking feature enables the transport of queued messages along with responses to any messages the client sends to the server over the channel. Piggybacking provides lightweight pseudo polling, where rather than the client channel polling the server on a fixed or adaptive interval, when the client sends a non-command message to the server (using a Producer or RemoteObject object), the server sends any pending data for client messaging or data management subscriptions along with the response to the client message. Piggybacking can also be used on a channel that has polling enabled but on a wide interval like 5 seconds or 10 seconds or more, in which case the application appears more responsive if the client is sending messages to the server. In this mode, the client sends a poll request along with any messages it sends to the server between its regularly scheduled poll requests. The channel piggybacks a poll request along with the message being sent, and the server piggybacks any pending messages for the client along with the acknowledge response to the client message.
• [login-after-disconnect] channel 配置可选项，默认值为 false 。如将该项设为 true ，则在 session 超时而造成的安全认证丢失的情况下客户端将尝试自动认证。在认证成功后会把上次发送失败的消息再次发送。通过这种方式来避免由于 session 超时而造成的认证失效对用户造成的影响。
• [flex-client-outbound-queue-processor] Optional channel property. Use to manage messaging quality of service for subscribers. Every client that subscribes to the server over this channel is assigned a unique instance of the specified outbound queue processor implementation that manages the flow of messages to the client. This can include message conflation, filtering, scheduled delivery and load shedding. You can define configuration properties, and if so, they are used to configure each new queue processor instance that is created. The following example shows how to provide a configuration property:
  

  <flex-client-outbound-queue-processor class="my.company.QoSQueueProcessor">
      <properties>
          <custom-property>5000</custom-property>
      </properties>
  </flex-client-outbound-queue-processor>

• [serialization] 用于支持早期的Flex版本的串行类型。
• [connect-timeout-seconds] channel 配置可选项，用于限定客户端通道的尝试连接时间。
• [invalidate-session-on-disconnect] endpoint 配置可选项, 默认值为 disabled 。如果设为 enabled ，session 将会随着 channel 的断开而失效。如果客户端在没有断开 channel 的情况下关闭，session 保持有效直至超时。
• [add-no-cache-headers] endpoint 配置可选项, 默认值为 true 。 用于指定是否让服务器在响应中加入 pragma no-cache 的 http 头信息，进而阻止浏览器缓存内容

 关于一般轮询：

    使用一般轮询需要在配置文件中设置 [polling-enable] 和 [polling-interval-seconds] 选项，或者无视配置文件直接在 Flex 中对 Channel 设置 pollingEnabled 和 pollingInterval 属性。一般轮询模式下，服务器对客户端的请求立即作出反应：如果消息队列中存在请求的消息则返回该消息否则返回一个空结果。

 

 

关于长轮询：

    使用长轮询需要在一般轮询的配置基础上增加 [wait-interval-millis] ，[max-waiting-poll-requests] 和 [client-wait-interval-millis]，其中最关键的是 [wait-interval-millis] 。在长轮询模式下，如果消息队列里不存在客户端要求的消息，那么服务器对于客户端的轮询并不立即作出响应，而是将该请求的响应挂起，进入等待状态。一旦该轮询请求的消息进入消息队列则处于等待状态的响应线程立即激活并传递消息给客户端。响应线程在等待状态下等待的最长时间由 [wait-interval-millis] 指定，endpoint 中可以同时存在多少个处于等待状态的响应线程由 [max-waiting-poll-requests] 指定，这个数量的设置需要充分考虑服务器对于的HTTP请求的最大负载。

 

 

BlazeDS的三种推模式：实时连接--能最敏捷的反映数据的变化，但客户端需要独占宝贵的连接资源，对服务器环境的要求最高；一般轮询--只能在特定周期上获取数据变化，请求完成后立即释放连接，比较节省服务器资源；长轮询--是前两者的折中方案，即不会长期占用连接，也能在一定程度上快速反映数据变化。选择哪种推模式需要在实际项目中根据具体需求做出选择。