できませんでした。orz
アドレスへアクセスして動作を確認しようとすると、一瞬、接続が確立されたように見えるのですが、その後すぐにConsumerがchannelFaultイベントをはき、ProducerもchannelFaultイベントをはく。そしてまた一瞬ConsumerがchannelConnectするものの、すぐにchannelFaultイベントをはくという動作になりました。結局接続が安定的に確立できず・・・
前回のMessagingのテスト状況からの変更点は以下。
1.WEB-INF/flex/services-config.xmlのchannelsにLongPollのチャンネルを追加
true
0
60000
3000
100
BlazeDSのドキュメントによると、polling-interval-secondsタグではなくpolling-interval-millisと書いてある部分もあるので、どちらも試してみました。動作は変わりませんでした。2.WEB-INF/flex/messaging-config.xmlのdefault-channelsにLongPollのチャンネルを追加
3. mxmlのChannelSetを変更
private function onClickButton():void{
consumer.unsubscribe();
if(local.selected){
pollAmfChannel.url="http://127.0.0.1:8080/messagebroker/amfpolling";
longPollAmfChannel.url="http://127.0.0.1:8080/messagebroker/myamflongpoll";
}else{
pollAmfChannel.url = "http://xxx.appspot.com/messagebroker/amfpolling";
longPollAmfChannel.url = "http://xxx.appspot.com/messagebroker/myamflongpoll";
}
consumer.subscribe();
}
]]>
ConsumerもProducerもchannelSetの値を{pollChannelSet}にすると、前回の状況と同じで、単純にpollingを使ったMessagingになります。それを、どちらも{longPollChannelSet}を指定したり、Consumerのみ{longPollChannelSet}にしたりしましたが、結局、安定的に接続が確立されませんでした。Comet的な処理はGAE/Jではできないという記事もあり、Long Pollingは今のところGAE/Jでは動作しないのかもしれません。Pullではなく、Push的な動作をGAE/J上で実現するには、何か別の手段を考えなければならない。
やはりダメぽか・・・
返信削除独自サーバーとかAmazonとかでやればできるのだろうけど、やはりGAEの圧倒的なコストパフォーマンスとスケーラビリティー、bigtableは捨てがたいもんなぁ〜
プッシュ的なのは何か別の方法を考えましょうo(´^`)o ウー