引用:
FCSとColdFusion&dBに分けています。
現在、クライアントが切断されると、サーバーサイドスクリプトで日時をゲットし、dBに書き込んでいます。
私も「切断」ボタンを押しているのに切断処理が行われないのが不思議なのです。何か別な要因があるのでしょうが、今のところ解りません。同様のケースの共通点を見出そうとしておりますが。。。
1.切断ボタンが押される
2.クライアントでは NetConnection.close が実行される
3.それに反応して、サーバーでは application.onDisconnect が実行される
4.サーバーサイドスクリプトで日付を取得
5.Flash Remoting
6.実際の切断処理
ということですね?
引用:
10回に1?2回程度上手くいかないのですが、言い方を変えれば8?9割はOKなのです。
まれに起きるということであれば、個人的には 2 ? 3 の部分か、5 のような気がします。
引用:
Flash->FlashRemoting->ColdFusion->MS-Accessで書き込んでいます。
記録目的は、デバッグ用です。
サーバーは混んでいる・・・という話でしたけれど、Flash Communication Server と Flash 側からほぼ同時刻くらいにアクセスして、ColdFusion や DB 側で要求待ち等は発生していないでしょうか?
あと、ColdFusion 側では DB でエラーが発生した場合の処理などは入っていますか?
引用:
今変えた訳ではないのですが、最初はデフォルトの900秒でした。その時は、おかしな記録の殆どがクライアントが切断した時間より15分位長い事になっておりました。そして設定を300秒に変更してからは、殆どが5分位長くなり、15分ってケースは無くなりました。なので「接続のタイムアウト」があやしいと思ったのです。
・サーバーサイドでの Flash Remoting
・クライアントのコンテンツからの Flash Remoting
の部分に、リトライの仕組みはありますか?
引用:
引用:どのくらいの時間で idle 状態になるかは不明です。(そういう設定は無さそう)
すぐにidle状態になってほしいですね。。。ちょっとでもヘンな事になったら、スパッと切断された事になってくれるとこのケースの場合は都合がいいのです。
すぐに idle になって切断されるような状態になると、今度は回線が混んでいる場合にはバシバシ切れるようになってしまいます(^^;
この辺はバランスが非常に難しい部分だと思います。
引用:
それは、検証している通信環境、マシンのスペックやコンディションが良いからなのかもしれませんね。
もし Flash Remoting の通信自体はアップデータのおかげで正常に行われているとしたら、この辺に左右されている部分があるのかもしれません。
もしそうであれば、Flash だけの問題ではない可能性もありますので、結構厄介な検証になりそうですね・・・