Что делать, если не удалось разрешить_store_upgrade?

Я использую neo4j на сервере Glassfish через модифицированную версию JCA-коннектора neo4j Alex Smirnov. Моя версия доступна здесь: https://github.com/Riduidel/neo4j-connector. м с помощью этого разъема с neo4j 1.8. Как следствие, когда я хочу его использовать, я сначала устанавливаю коннектор на моем сервере приложений Glassfish, а затем использую этот коннектор в приложениях, к которым нужно подключиться.

Он работает нормально при использовании его со свежими магазинами. Но при использовании его с магазинами, созданными в предыдущей версии, я сталкиваюсь со странными ошибками.

Как правило, я получил сегодня следующий стек

javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader@3bbd53b1 from NONE to STOPPED
...
...
.../* JCA internal exception stack */
...
...
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader@494b584c from NONE to STOPPED
 at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:924)
 at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1185)
 at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
 ... 66 more
Caused by: org.neo4j.kernel.lifecycle.LifecycleException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader@494b584c from NONE to STOPPED
 at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:388)
 at org.neo4j.kernel.lifecycle.LifeSupport.init(LifeSupport.java:82)
 at org.neo4j.kernel.lifecycle.LifeSupport.start(LifeSupport.java:116)
 at org.neo4j.kernel.InternalAbstractGraphDatabase.run(InternalAbstractGraphDatabase.java:227)
 at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:79)
 at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:70)
 at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:165)
 at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:127)
 at com.netoprise.neo4j.Neo4jManagedConnectionFactory.createManagedConnection(Neo4jManagedConnectionFactory.java:163)
 at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:160)
 at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
 ... 68 more
Caused by: java.lang.AssertionError
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:265)
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
 at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
 at org.neo4j.index.impl.lucene.LuceneDataSource.<init>(LuceneDataSource.java:185)
 at org.neo4j.index.lucene.LuceneIndexProvider.load(LuceneIndexProvider.java:72)
 at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.loadIndexImplementations(InternalAbstractGraphDatabase.java:1171)
 at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.init(InternalAbstractGraphDatabase.java:1143)
 at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:382)
 ... 78 more

Быстрая проверка показывает, что это исключение связано с неудаляемым файлом «write.lock». Мой файл write.lock не может быть удален, поскольку я думаю миграция еще не завершена. Как я могу убедиться, что миграция выполнена, прежде чем использовать ее, не перенося ее за пределы Glassfish?

Есть ли способ получить эксклюзивную миграцию магазина в этом контексте? И если да, то как? И это решение моей проблемы?

EDIT 1 Добавлено сообщение об исключении.

EDIT 2 Все это происходит только тогда, когда загруженный граф ранее использовался с Neo4j 1.5, а теперь с разъемом Neo4j 1.8. когда граф создается соединителем, абсолютно никакой ошибки не происходит.

EDIT 3 Как ни странно, это происходит до тех пор, пока к этому коду не подключен отладчик: как только я пытаюсь его отладить, проблема перестает появляться. Это наводит меня на мысль, что может существовать механизм очистки миграции, который снимает блокировку записи после завершения миграции, и эта очистка не выполняется при использовании моего коннектора JCA neo4j. Это верное наблюдение?


neo4j glassfish jca
person Riduidel    schedule 08.04.2013    source источник
comment
Очистка блокировок записи происходит до любых проверок обновления чего-либо. Я не вижу связи с апгрейдом в данном случае. И то, что он не появляется при отладке, тоже очень странно. То есть после успешного запуска и выключения в режиме отладки при повторном запуске не работает?   -  person Mattias Finné    schedule 11.04.2013

Ответы (2)


arrow_upward
1
arrow_downward

Я не очень хорошо знаком с коннектором JCA, но, чтобы быть уверенным, я бы просто написал очень маленький класс Java для миграции, который открывает базу данных, позволяет ей мигрировать и выключается. Затем попробуйте еще раз с разъемом JCA?

person Peter Neubauer    schedule 08.04.2013
comment
Извините, я только что добавил исходное сообщение об исключении. - person Riduidel; 08.04.2013
comment
или используйте neo4j-shell -path path/to/db -config config-with-allow-auto-upgrade-neo4j.properties - person Michael Hunger; 09.04.2013
comment
@MichaelHunger, поэтому я не буду использовать встроенный neo4j для выполнения миграции, а буду использовать внешний. Верно ? К сожалению, мне нужна автоматическая миграция с моего коннектора neo4j. Я не говорю, что это плохое решение, просто это решение отлично подходит для теста. На самом деле самый большой недостаток этого решения заключается в том, что мне потребовалось бы развертывать независимые экземпляры neo4j на каждой машине, где развернуто мое приложение... странно, учитывая тот факт, что мой коннектор содержит работающее ядро ​​neo4j. - person Riduidel; 09.04.2013
comment
@MichaelHunger Похоже, это сработало без каких-либо проблем, что меня более чем озадачило. Как выполняется миграция Lucene с помощью оболочки Neo4j? И чем это отличается от того, что может делать мой разъем? - person Riduidel; 09.04.2013

arrow_upward
0
arrow_downward

После дальнейших расследований выяснилось, что правда заключается не в нескольких вызовах конструктора EmbeddedGraphDatabase, а в нескольких загружаемых идентификаторах IndexProvider.

Я использую neo4j, встроенный в разъем JCA с открытым исходным кодом. В этом соединителе класс org.neo4j.kernel.Service заменен на специальный, который содержит обходной путь в отношении загрузки службы для неразделяемых библиотек JBoss. К сожалению, в нашем контексте этот обходной путь подразумевает двойную загрузку провайдера индекса:

  1. один раз с помощью загрузчика классов EAR
  2. один раз с помощью загрузчика классов библиотеки Glassfish.

Почему ? Поскольку наш экземпляр neo4j используется для данных приложения И для аутентификации, jar коннектора neo4j помещается в ${domain}/lib. Как следствие, из-за делегирования загрузчика классов на сервере приложений загрузчик классов EAR делегирует загрузчику классов библиотеки Glassfish и таким образом находит файл LuceneIndexProvider. Затем загрузчик классов библиотеки Glassfish напрямую используется для загрузки того же класса LuceneIndexProvider.

Это завершается тем, что у нас есть два объекта LuceneIndexProvider, оба пытаются перенести индекс lucene. Что приводит к AssertionError, поскольку файл write.lock, созданный первым объектом, должен быть удален вторым, который не может этого сделать.

Затем я немного изменил этот очень специфический класс, чтобы использовать обходной путь JBoss только тогда, когда механизм загрузки по умолчанию не возвращает никакого класса (см. коммит здесь). Это небольшое изменение сработало как волшебство, поэтому я думаю, что вы можете считать эту проблему исправленной.

person Riduidel    schedule 16.04.2013