Spring Data Neo4j 4.0.0: StackOverFlowError

Я использую Spring Data Neo4j 4.0.0 с Neo4j 2.2.1 и пытаюсь импортировать объект, похожий на дерево времени, с двумя уровнями под корнем. Сохраненный объект создается и сохраняется в конце, и в какой-то момент процесса сохранения я получил эту ошибку StackOverFlow:

Exception in thread "main" java.lang.StackOverflowError
        at java.lang.Character.codePointAt(Character.java:4668)
        at java.util.regex.Pattern$CharProperty.match(Pattern.java:3693)
        at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
        at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
        at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
    at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
    at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466)
    at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)
    at java.util.regex.Pattern$Curly.match0(Pattern.java:4177)
    at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
    at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
    at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
    at java.util.regex.Pattern$Branch.match(Pattern.java:4500)
    at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3715)
    at java.util.regex.Pattern$Start.match(Pattern.java:3408)
    at java.util.regex.Matcher.search(Matcher.java:1199)
    at java.util.regex.Matcher.find(Matcher.java:618)
    at java.util.Formatter.parse(Formatter.java:2517)
    at java.util.Formatter.format(Formatter.java:2469)
    at java.util.Formatter.format(Formatter.java:2423)
    at java.lang.String.format(String.java:2792)
    at org.neo4j.ogm.cypher.compiler.IdentifierManager.nextIdentifier(IdentifierManager.java:48)
    at org.neo4j.ogm.cypher.compiler.SingleStatementCypherCompiler.newRelationship(SingleStatementCypherCompiler.java:71)
    at org.neo4j.ogm.mapper.EntityGraphMapper.getRelationshipBuilder(EntityGraphMapper.java:357)
    at org.neo4j.ogm.mapper.EntityGraphMapper.link(EntityGraphMapper.java:315)
    at org.neo4j.ogm.mapper.EntityGraphMapper.mapEntityReferences(EntityGraphMapper.java:262)
    at org.neo4j.ogm.mapper.EntityGraphMapper.mapEntity(EntityGraphMapper.java:154)
    at org.neo4j.ogm.mapper.EntityGraphMapper.mapRelatedEntity(EntityGraphMapper.java:524)
    at org.neo4j.ogm.mapper.EntityGraphMapper.link(EntityGraphMapper.java:324)
    at org.neo4j.ogm.mapper.EntityGraphMapper.mapEntityReferences(EntityGraphMapper.java:262)
    at org.neo4j.ogm.mapper.EntityGraphMapper.mapEntity(EntityGraphMapper.java:154)
    at org.neo4j.ogm.mapper.EntityGraphMapper.mapRelatedEntity(EntityGraphMapper.java:524)
...

Заранее спасибо, и ваше предложение будет действительно оценено!


runtime-error import neo4j stack-overflow spring-data-neo4j-4
person Peter Sie    schedule 03.06.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

SDN 4 на самом деле не предназначен для пакетного импорта ваших объектов в Neo4j. Это фреймворк Object Graph Mapping для Java-приложений общего назначения, а не пакетный импортер (который приносит свой собственный специфический набор проблем). Некоторые проектные решения для поддержки предполагаемого варианта использования SDN противоречат тому, что вы бы сделали, если бы пытались разработать ETL для конкретной цели. Мы также ограничены производительностью конечной точки транзакций HTTP Neo4j, которая, хотя и не медленная в абсолютном выражении, не может конкурировать, например, с Batch Inserter.

Есть некоторые улучшения производительности, которые мы будем делать в будущем, и когда будет выпущен новый бинарный протокол для Neo4j (2.3), мы включим его в качестве нашего протокола передачи. Мы ожидаем, что это улучшит скорость передачи данных в базу данных и из нее как минимум на порядок. Однако не ожидайте, что эти изменения радикально изменят поведенческие характеристики SDN 4. Хотя будущая версия может загружать несколько тысяч узлов намного быстрее, чем в настоящее время, она по-прежнему не будет инструментом ETL, и я не ожидал, что он будет использоваться как таковой.

person Vince    schedule 03.06.2015

arrow_upward
0
arrow_downward

После нескольких часов проб и ошибок, наконец, я обнаружил, что мне нужно ограничить уровень глубины сохранения.

Раньше я не указывал уровень глубины, и сохраняемый объект становился все больше и больше, так как вставка его дочерних элементов также выполнялась одновременно. Итак, указав глубину 1 для каждого метода сохранения, я, наконец, избавился от ошибки StackOverFlow. И, не сохраняя регулярно (я помещаю все объекты в ArrayList и сохраняю их все в конце), я получаю прирост производительности на 1 минуту (с 3,5 до 2,5 минут) для импорта ок. 1000 узлов (с отношениями).

Тем не менее, производительность по-прежнему неудовлетворительна, так как я мог импортировать более 60 000 данных менее чем за 1 минуту с моей предыдущей реализацией MongoDB. Я не знаю, связано ли это с SDN4 и может ли это быть быстрее с Embedded API. Мне действительно любопытно, проводил ли кто-нибудь бенчмаркинг SDN4 и Embedded API.

person Peter Sie    schedule 03.06.2015
comment
Спасибо за обновление Питер. Пара вещей: SDN4 на данный момент создан для работы с удаленным сервером Neo4j, поэтому встроенный в данный момент не рассматривается. В более позднем выпуске будет больше внимания производительности. Импорт с использованием SDN, вероятно, не очень хорошая идея. Будет ли иметь какое-либо значение, если вы отрегулируете размер стека Java -Xss? Наконец, если есть какой-то способ поделиться этой частью кода с нами в частном порядке вместе с вашими данными об окружении java, пожалуйста, сделайте это. Спасибо - person Luanne; 03.06.2015
comment
Нет, изменение размера стека java не помогает. Я попытался настроить его на 1 МБ, но производительность осталась прежней. Если бы вы просмотрели мой код в частном порядке, я был бы очень рад. Несмотря на это, я думаю, что использовать SDN4 в моем случае — не очень хорошее решение. - person Peter Sie; 03.06.2015
comment
Жаль это слышать. Я все же хотел бы взглянуть на ваш код. Моя электронная почта luanne at graphaware dot com - person Luanne; 03.06.2015