組み込みモードで Neo4j の v1.9.1 (最新の安定リリース) を実行しています。プロセスが予期せずシャットダウンし、neo4j.shutdown() が呼び出されないという状況がいくつかありました。注: これが発生すると、neoDB に未解決の更新や変更が発生していないことがわかります。また、これはLinux OS上にあります。
アプリケーションが再起動され、neo4j への接続が開始されると、回復プロセスが開始されますが、永久にハングします。messages.log ファイルには次の情報が表示されます。
2013-07-17 21:05:09.143+0000 INFO [o.n.k.i.t.x.XaLogicalLog]: XaResourceManager[nioneo_logical.log] recovery completed.
2013-07-17 21:05:09.143+0000 INFO [o.n.k.i.t.x.XaLogicalLog]: Recovery on log [/opt/pricing/data/database/app/nioneo_logical.log.1] completed.
2013-07-17 21:05:09.156+0000 INFO [o.n.k.i.t.TxManager]: TM opening log: /opt/pricing/data/database/app/tm_tx_log.2
2013-07-17 21:05:09.245+0000 INFO [o.n.b.BackupServer]: BackupServer communication server started and bound to /0.0.0.0:6362
2013-07-17 21:05:09.271+0000 INFO [o.n.k.i.t.x.XaLogicalLog]: Non clean shutdown detected on log [/opt/pricing/data/database/app/index/lucene.log.2]. Recovery started ...
2013-07-17 21:05:09.271+0000 INFO [o.n.k.i.t.x.XaLogicalLog]: [/opt/pricing/data/database/app/index/lucene.log.2] logVersion=3 with committed tx=317
最も興味深いのは、DB をデスクトップにコピーし、DB を起動してシャットダウンし、DB に対して実行するだけの小さなプログラムを作成したことです。問題はなく、ほんの数秒で回復しました (これは、ハング プロセスが DB を部分的に回復したためかもしれませんが、DB を強制終了して再度実行すると、アプリケーションが DB を回復するため、そうではないと思います)。これを Linux マシンで繰り返し、同じ結果が得られました。
私たちは明らかに、アプリケーションの予期しない終了時にシャットダウンが常に呼び出されるようにすることに取り組んでいますが、本当の問題は、起動時に回復プロセスがハングするのはなぜですか? 次のhttps://groups.google.com/forum/#!msg/neo4j/CBvuMybTRFw/NMIOpBjrIYIJを見つけましたが、DB をサーバーとして実行し、タイムアウトを増やすだけです。messages.log のポイントは私の場所とまったく同じですが。
リカバリがハングした場合の一時的な解決策として、小さな「ダミー」プログラムを実行して、DB が修正されるかどうかを確認できますが、むしろ根本的な原因に到達する必要があります。
誰かアドバイスはありますか？