| | 1 | = CSS Archiver でのIOC再接続問題 = |
| | 2 | |
| | 3 | CSS Archiver 3.2.16での運用中に接続していたIOCが再起動した場合、IOCとの再接続が行われたにも関わらずデータがDBに保存されないという問題が度々聞かれるようになった。[[br]] |
| | 4 | 以前はあまり聞かなかったのか気付かなかったのかは不明だが、cERLでも主空洞グループのMW100用のIOCとの接続で頻発することを確認した。ここで確認した現象としては、同じIOC内のレコードでもデータ保存を開始するまでにかかる時間のバラツキが大きく、最長で3日経ってから保存し始めたものがあった。[[br]] |
| | 5 | 始めはIOC辺りのレコード数が多すぎるのが問題かと考え、現象を認識してもCSS Archiverを再立ち上げしたり、現象を認識したときには既にDBへの保存が始まっていたりして、対処することはしていなかった。[[br]] |
| | 6 | ここにきて、KEKBでも同様の現象がみられるとのことで、KEKBの佐々木さんと関東情報サービスの廣瀬さんが色々と調べたところ、CSS Archiverに問題があることが判明した。[[br]] |
| | 7 | |
| | 8 | == 症状 == |
| | 9 | |
| | 10 | 現象と症状はKEKBのwikiに記述があるが、参照できない人もいると思われるので画面キャプチャを載せておく。 |
| | 11 | |
| | 12 | [[Image(CSSArchiveEngineFailSS1.png, 200px)]][[Image(CSSArchiveEngineFailSS2.png, 200px)]] |
| | 13 | |
| | 14 | この画像に記載されているようにCSS Archiver側でのLastArchiveValueの処理に問題があり、接続はされているがデータはCSS Archiverに保存されない状態になるパターンがあるとのことだった。 |
| | 15 | |
| | 16 | |
| | 17 | == 対処方法 == |
| | 18 | |
| | 19 | wikiにも記載されているようにレコード側ではPINIを設定すればこの問題は解決するようだが、既に存在して運用されている全てのIOCにそれを行うのは現実的ではない。[[br]] |
| | 20 | 根本的には、CSS Archiver側で対処するのが正しい方向であろう。[[br]] |
| | 21 | |
