4D Serverへの接続後にスリープしたClientを自動的に解除するには
2 posters
4D Serverへの接続後にスリープしたClientを自動的に解除するには
Macで4D Server v16-64bitを使っていますが,32bitでも同じことが起こります。
4D Serverへの接続後に解除しないままスリープしたClientがそのまま残る様になりました。データベース設定で,接続のタイムアウトを5分に設定していますが,スリープしたMacが5時間以上接続されたことになっており,再び作業を開始した時に別のユーザーとして接続され,ライセンスの上限に達してしまう様になりました。
そのスクリーンショットです。2つのClientが重複しています。
スリープしたClientを自動的に解除するには,どうすればいいでしょうか。
4D Serverへの接続後に解除しないままスリープしたClientがそのまま残る様になりました。データベース設定で,接続のタイムアウトを5分に設定していますが,スリープしたMacが5時間以上接続されたことになっており,再び作業を開始した時に別のユーザーとして接続され,ライセンスの上限に達してしまう様になりました。
そのスクリーンショットです。2つのClientが重複しています。
スリープしたClientを自動的に解除するには,どうすればいいでしょうか。
M_Fujihara- 投稿数 : 86
登録日 : 2016/12/03
Re: 4D Serverへの接続後にスリープしたClientを自動的に解除するには
データベース設定の『サーバー/クライアント接続タイムアウト(データベース設定#13,および#14)』を「5分」に設定されているとのことですが,ドキュメントにも記述されているように,この設定は,64ビット版(新ネットワークレイヤー)では『無視されます』。
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/SET-DATABASE-PARAMETER.301-3111776.ja.html
32ビット版(旧ネットワークレイヤー)では,『クライアントが動作していることを示す信号をサーバが受信する』という仕組みがありました。クラッシュまたはフリーズしたクライアントを『見捨てる』ためです。何も操作していない(アイドル状態)なクライアントは,その信号を発信しているので,タイムアウトがどうであれ,不意に接続を切断されることはありません。通常であれば『5分』などという設定値は考えられません。クライアントがサーバーと5分間も通信できないほどビジーになるためには,コンパイルモードで,ひとつのプロセスが全力で処理を続けなければならないからです。基本的に,デフォルトの設定,1~2分程度がもっとも安定しています。
この仕組みは,クラッシュまたはフリーズしたクライアントを検出するには役立ちましたが,スリープしたクライアントに対応できない,という致命的な欠点がありました。32ビット版(旧ネットワークレイヤー)では,クライアントがいかなるときもサーバーと接続中であることが前提になります。洗練されたネットワークアプリケーションは,スリープの直前にシステムから通知を受け取り,接続情報(アプリケーション特有のコンテキスト情報)を保存し,ソケットを閉じるように書かれています。そして,スリープ解除の通知を受け取ったら,新しいソケットを開き,接続情報を復元して中断されたセッションを再開します。64ビット版(新ネットワークレイヤー)では,こうした仕組みが4Dのクライアント/サーバーにも実装されました。
クライアントがスリープした場合,従来であれば,復帰直後に『深刻なエラー』が表示され,終了または再接続するしかありませんでした。64ビット版(新ネットワークレイヤー)では,そのようなクライアントの接続情報がサーバーとクライアントの両方で保持され,スリープ解除後にそのまま操作が続けられるようになっています。
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/Users-Page.300-3176521.ja.html
ですから『4D Serverへの接続後に解除しないままスリープしたClientがそのまま残る』のは正しい動作ですが,スリープ解除後,『何事もなかったかのように』そのクライアントをそのまま使い続けることができないのであれば,それは確かに問題です。
『再び作業を開始した時に別のユーザーとして接続され』るとのことですが,再び作業を開始したときには,クライアント側でログイン等の手続きを踏んでいるのでしょうか。想像ですが,『再び作業を開始した時』に以前のクライアントの再開を待ちきれずに強制終了したりはしていないでしょうか。前述したように,データベース設定の『サーバー/クライアント接続タイムアウト』はもう存在しませんので,そうであれば,問題があります。
仕様は『接続後に以前のセッションが再開される』ことですので,それと矛盾するように『接続後にスリープしたClientを自動的に解除する』ことは想定されていません。
参考までに
16.0のリリース後,下記の不具合がNightly Buildで修正されています。
ACI0095470 新ネットワークレイヤーのみ。30秒ほどクライアントマシンをスリープさせてからマシンのスリープを解除した場合,4Dがスリープから復帰しませんでした。
https://github.com/4D-JP/release-notes/tree/master/v16/16.1
ドキュメントに記述されているように,スリープからの自動復帰は,
1 昼休み
2 週末
を想定した設計になっています。それで48時間経っても眠りから帰らないクライアントは,ドロップされます。とはいえ,連休中,ずっとスリープしたいとか,あるいはもっと短いタイムアウトでユーザーをドロップしたい,といった管理要求があるかもしれません。現在,48時間はハードコーディングされた値ですが,将来のバージョンではSET DATABASE PARAMETERでこれを変更できるようにするという案を検討中です。
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/SET-DATABASE-PARAMETER.301-3111776.ja.html
32ビット版(旧ネットワークレイヤー)では,『クライアントが動作していることを示す信号をサーバが受信する』という仕組みがありました。クラッシュまたはフリーズしたクライアントを『見捨てる』ためです。何も操作していない(アイドル状態)なクライアントは,その信号を発信しているので,タイムアウトがどうであれ,不意に接続を切断されることはありません。通常であれば『5分』などという設定値は考えられません。クライアントがサーバーと5分間も通信できないほどビジーになるためには,コンパイルモードで,ひとつのプロセスが全力で処理を続けなければならないからです。基本的に,デフォルトの設定,1~2分程度がもっとも安定しています。
この仕組みは,クラッシュまたはフリーズしたクライアントを検出するには役立ちましたが,スリープしたクライアントに対応できない,という致命的な欠点がありました。32ビット版(旧ネットワークレイヤー)では,クライアントがいかなるときもサーバーと接続中であることが前提になります。洗練されたネットワークアプリケーションは,スリープの直前にシステムから通知を受け取り,接続情報(アプリケーション特有のコンテキスト情報)を保存し,ソケットを閉じるように書かれています。そして,スリープ解除の通知を受け取ったら,新しいソケットを開き,接続情報を復元して中断されたセッションを再開します。64ビット版(新ネットワークレイヤー)では,こうした仕組みが4Dのクライアント/サーバーにも実装されました。
クライアントがスリープした場合,従来であれば,復帰直後に『深刻なエラー』が表示され,終了または再接続するしかありませんでした。64ビット版(新ネットワークレイヤー)では,そのようなクライアントの接続情報がサーバーとクライアントの両方で保持され,スリープ解除後にそのまま操作が続けられるようになっています。
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/Users-Page.300-3176521.ja.html
ですから『4D Serverへの接続後に解除しないままスリープしたClientがそのまま残る』のは正しい動作ですが,スリープ解除後,『何事もなかったかのように』そのクライアントをそのまま使い続けることができないのであれば,それは確かに問題です。
『再び作業を開始した時に別のユーザーとして接続され』るとのことですが,再び作業を開始したときには,クライアント側でログイン等の手続きを踏んでいるのでしょうか。想像ですが,『再び作業を開始した時』に以前のクライアントの再開を待ちきれずに強制終了したりはしていないでしょうか。前述したように,データベース設定の『サーバー/クライアント接続タイムアウト』はもう存在しませんので,そうであれば,問題があります。
仕様は『接続後に以前のセッションが再開される』ことですので,それと矛盾するように『接続後にスリープしたClientを自動的に解除する』ことは想定されていません。
参考までに
16.0のリリース後,下記の不具合がNightly Buildで修正されています。
ACI0095470 新ネットワークレイヤーのみ。30秒ほどクライアントマシンをスリープさせてからマシンのスリープを解除した場合,4Dがスリープから復帰しませんでした。
https://github.com/4D-JP/release-notes/tree/master/v16/16.1
ドキュメントに記述されているように,スリープからの自動復帰は,
1 昼休み
2 週末
を想定した設計になっています。それで48時間経っても眠りから帰らないクライアントは,ドロップされます。とはいえ,連休中,ずっとスリープしたいとか,あるいはもっと短いタイムアウトでユーザーをドロップしたい,といった管理要求があるかもしれません。現在,48時間はハードコーディングされた値ですが,将来のバージョンではSET DATABASE PARAMETERでこれを変更できるようにするという案を検討中です。
miyako- 投稿数 : 485
登録日 : 2016/07/05
Re: 4D Serverへの接続後にスリープしたClientを自動的に解除するには
ありがとうございます。
v16 32bitでタイムアウトを1分にしていますが,今朝も上記2重ログインを起こした様です。
>想像ですが,『再び作業を開始した時』に以前のクライアントの再開を待ちきれずに強制終了
>したりはしていないでしょうか。
強制終了したと言うか,せざるを得なかった様です。おそらく2〜3分はレインボーカーソルが回っていたと思います。どの位で4Dに復帰出来るか後ほど実験して報告しますが,2〜3分でも仕事に差し支えます。
v16 32bitでタイムアウトを1分にしていますが,今朝も上記2重ログインを起こした様です。
>想像ですが,『再び作業を開始した時』に以前のクライアントの再開を待ちきれずに強制終了
>したりはしていないでしょうか。
強制終了したと言うか,せざるを得なかった様です。おそらく2〜3分はレインボーカーソルが回っていたと思います。どの位で4Dに復帰出来るか後ほど実験して報告しますが,2〜3分でも仕事に差し支えます。
M_Fujihara- 投稿数 : 86
登録日 : 2016/12/03
Re: 4D Serverへの接続後にスリープしたClientを自動的に解除するには
返信ありがとうございます。
前述したBUGの件があるので,Nightly Buildであれば,あるいは解消されているのかもしれません。
クライアントが32ビット版であっても,サーバーが64ビット版であれば,必然的に新ネットワークレイヤーとなります。
64ビット版のクライアントではいかがでしょうか。
前述したBUGの件があるので,Nightly Buildであれば,あるいは解消されているのかもしれません。
クライアントが32ビット版であっても,サーバーが64ビット版であれば,必然的に新ネットワークレイヤーとなります。
64ビット版のクライアントではいかがでしょうか。
miyako- 投稿数 : 485
登録日 : 2016/07/05
Re: 4D Serverへの接続後にスリープしたClientを自動的に解除するには
4D(アプリ)に大変失礼なことを言ってしまったようです。
4D Server v16-32bit, 64bit版ともにClientのスリープから10秒で復帰し,入力出来る様になりました。ただレインボーカーソルが回るだけで,クリックしてもキーボードをたたいても何も変化がないので,知らないとフリーズした様に見えます。最初の画面に「動かないように見えても10秒待とう」と書こうと思います。
でもまだ解決しないといけない問題があります。
4D Server v16-32bit, 64bit版ともにClientのスリープから10秒で復帰し,入力出来る様になりました。ただレインボーカーソルが回るだけで,クリックしてもキーボードをたたいても何も変化がないので,知らないとフリーズした様に見えます。最初の画面に「動かないように見えても10秒待とう」と書こうと思います。
でもまだ解決しないといけない問題があります。
M_Fujihara- 投稿数 : 86
登録日 : 2016/12/03
Re: 4D Serverへの接続後にスリープしたClientを自動的に解除するには
訂正です。
32bit版を使っていますが,前述のようにスリープ後に短時間で復帰出来る場合と,15分以上経っても復帰出来ず,強制終了せざるを得ない場合があるようです。どういう場合にそれぞれになるかという条件は,まだ見つけていません。
32bit版を使っていますが,前述のようにスリープ後に短時間で復帰出来る場合と,15分以上経っても復帰出来ず,強制終了せざるを得ない場合があるようです。どういう場合にそれぞれになるかという条件は,まだ見つけていません。
M_Fujihara- 投稿数 : 86
登録日 : 2016/12/03
Re: 4D Serverへの接続後にスリープしたClientを自動的に解除するには
スリープで復帰出来なくなったClientをサーバー上で終了にさせないと,そのスリープしたレコードの入力が不完全になることが分かりました。
「レコードは編集中で更新出来ません」なら良いのですが,フィールドによって入力が出来る所と出来ない所があり,保存が出来るので,動作がおかしいという印象を持たれてしまいます。
「レコードは編集中で更新出来ません」なら良いのですが,フィールドによって入力が出来る所と出来ない所があり,保存が出来るので,動作がおかしいという印象を持たれてしまいます。
M_Fujihara- 投稿数 : 86
登録日 : 2016/12/03
Permissions in this forum:
返信投稿: 不可
|
|