OpenDolphin日記

最近、KVMのイメージファイルをバックアップ転送する際、開始直後は270MB/s以上の高速なスループットを維持するものの、後半にかけて顕著に速度が低下するのに気付いた。バックアップは自動で行っているので、いつから症状があったかは不明。調査したところ、この症状は特定のデバイスに依存せず発生したため、ネットワークインフラに起因するものと推測した。

1. 原因の切り分け

検証のため、予備の8ポート安ハブに交換して転送試験を行ったところ、速度低下なく転送された。これにより、ほぼ半額で購入した中古再生備品業務用ハブに原因があることが推定された。メーカーであるバッファローさんのWebサイトを確認したところ、旧版ファームウェアにおいて転送速度が低下する既知の不具合が記載されていた。実機のファームウェアバージョンを確認したところ、該当する古いバージョン（Ver.1.5.1.03 [2024/03/12]）であることが判明した。

2. ファームウェアアップデートの実施とトラブル

不具合解消のため、最新のファームウェア（Ver.1.7.1.11 [2025/11/25]）へのアップデートを実施した。書き換え作業自体は正常に終了し、システム再起動が開始された。しかし、再起動開始後、しばらく待ってもハブのインジケーターが一切反応せず、通信もできず文鎮化したと判断せざるを得ない状況に陥った。復旧には時間を要すると考え、代替の安ハブへの交換作業を進めていたところ、約5分程度？が経過した時点で、文鎮化したと思っていたハブが正常に動作して、通信が再開されているのに気付いた。

3. 結果と考察

ログインしてステータスを確認したところ、ファームウェアは正常に Ver.1.7.1.11 へ更新されていた。改めてファイル転送試験を行った結果、当初の問題であった速度低下も解消されていた。今回の事例から、当該製品のファームウェアアップデートに伴う再起動には、予想外の長い時間を要する場合があることがわかった。単なるハブだと思って舐めていたが、業務用ハブは奥が深い。

IME 切換で、メニューバーの OCR までやって苦労していたら、masuda 先生が、手動で切り替えた場合も現在の状態を取得できる自作プログラム MacImSelect を教えてくれた。

以前 Foreign Function and Memory (FFM) API で挑戦したときは、入力ソース関連関数が Swing スレッドとバッティングして、どうにもできなかったのだが、masuda 先生は _dispatch_main_q スレッドで処理させることで、スマートに回避していた。さらに NSTextInputContext.currentInputContext で現在の inputContext を取得して操作していて、手動で切り替えても現在の状態が取れるのはここが、一体ポイントかもしれない。うちの TISServer のように、外部プロセスに処理させた場合は、呼び出し側がどの NSTextInputContext を使っているかなど知るよしもないので、どうにもならない。

教えてもらった MacImSelect は JNA で書かれていたので、これを参考にしながら、FFM API で、レベルの低いプログラムに挑戦、試行錯誤の末、何とか動くようにできた。(AppKit 版と Carbon 版)

基本的な流れとしては、入力ソース切換関係の関数を呼ぶときに、dispatch_sync_f(dispatch_queue_t queue, void * context, dispatch_function_t work) で _dispatch_main_q スレッドに処理を委託するのだが、委託先のネイティブからは、work(context) の形で呼ばれるので、その形の upcallStub を作成、さらに context 内に共通メモリ領域を作って、スレッドの異なる java とは、その領域で同期的にデータのやりとりをするという方式だ。