BlazeDS のプッシュ機能（その３）

<channel-definition id="polling-piggybacking-amf" class="mx.messaging.channels.AMFChannel">
<properties>
  <polling-enabled>true</polling-enabled>
  <polling-interval-millis>10000</polling-interval-millis>
  <piggybacking-enabled>true</piggybacking-enabled>
  ...
 

ロングポーリングのときと同様に polling-enabled を true にしてポーリング機能を有効にします。そして、polling-interval-millis には 10000 を設定しています。これは 10 秒間隔でポーリングリクエストを送信するようにという指定です。

polling-interval-millis の値を小さくするほどリアルタイム度が高くなります。（ロングポーリングでは 0 でした） が、その分余計なオーバヘッドが発生しますし、無駄なリクエストの数も増える可能性があります。この方法はせいぜい数秒に一度情報が更新されれば大丈夫といった使い方が向いていそうです。

ロングポーリングの例と違い、上のサンプルでは wait-interval-millis を明示的に指定していません。サーバ側はリクエストを受けたら直ぐに返信するという動きにしたいので、デフォルト値 （0） から変更する必要が無いためです。

あとは、piggybacking-enabled を true にしておくことで定期的なポーリング以外のタイミングでも情報を受け取れるようになります。効果の程は、どのくらいアクティブにクライアント側でのインタラクションが行われるかによりそうですね。

この方法は、前の 2 つの方法と違ってサーバのスレッドをブロックする必要がありません。そのため、スケーラビリティの面からは有利だと考えられます。とはいえ、サーバ一台辺りが処理できる数は数百のオーダーだと思われるので、よりスケーラビリティの必要な環境では BlazeDS の代わりに LCDS の利用も検討してみてください。

最後に、この方法に限らず、サーバからのプッシュと RPC に個別のチャネルを使用する必要はありません。効率的なリソース使用の観点からは一つの ChannelSet で RPC やサーバからのプッシュやデータ管理用コンポーネント全てをまかなうようにすることをお勧めします。