CSS Archiver でのIOC再接続問題

CSS Archiver 3.2.16での運用中に接続していたIOCが再起動した場合、IOCとの再接続が行われたにも関わらずデータがDBに保存されないという問題が度々聞かれるようになった。
以前はあまり聞かなかったのか気付かなかったのかは不明だが、cERLでも主空洞グループのMW100用のIOCとの接続で頻発することを確認した。ここで確認した現象としては、同じIOC内のレコードでもデータ保存を開始するまでにかかる時間のバラツキが大きく、最長で3日経ってから保存し始めたものがあった。
始めはIOC辺りのレコード数が多すぎるのが問題かと考え、現象を認識してもCSS Archiverを再立ち上げしたり、現象を認識したときには既にDBへの保存が始まっていたりして、対処することはしていなかった。
ここにきて、KEKBでも同様の現象がみられるとのことで、KEKBの佐々木さんと関東情報サービスの廣瀬さんが色々と調べたところ、CSS Archiverに問題があることが判明した。

症状

現象と症状はKEKBのwikiに記述があるが、参照できない人もいると思われるので画面キャプチャを載せておく。

この画像に記載されているようにCSS Archiver側でのLastArchiveValueの処理に問題があり、接続はされているがデータはCSS Archiverに保存されない状態になるパターンがあるとのことだった。

対処方法

wikiにも記載されているようにレコード側ではPINIを設定すればこの問題は解決するようだが、既に存在して運用されている全てのIOCにそれを行うのは現実的ではない。
根本的には、CSS Archiver側で対処するのが正しい方向であろう。

KEKBの佐々木さんがgithubのbugfixを調べてくれて、KEK版CSSの元になっているソースコードがコミットされた以降に別の問題で行われたbugfixで解決できそうだということだった。

​o.a.archive.engine: Check for invalid time stamps

これを元にgithubを見ていたところ、その次にbugfixされていたところでもよさそうだった。
なるべく新しいほうがいいだろうということで、こちらの変更をマージしてテストしてみた。

​o.c.archive.engine: Fix 'isConnected' NPE when PVManager not started

これ以降のbugfixは、かなり大幅は変更(基底クラスの追加等)が行われていたので、今回は使うことができなかった。

始めは私がcERLの運用機で実験してみたが、現象としてはConnectedだったのがDisconnectedになったので接続できないことが明確になっただけで問題の解決にはならなかった。
廣瀬さんに仮想マシン上で追試をお願いしたところ、そちらでは問題が解決したとの報告をうけた。
こちらは運用機での実験だったので、リビルドしたファイルを上書きインストールしていた。
バックアップを作成後に、クリーンインストールをして再実験したところ、こちらでも問題なく再接続がされるようになった。