Утечка связи в JanusGraph / tinkerpop - PullRequest
1 голос
/ 09 января 2020

Я подключаюсь к janusGraph удаленно через

cluster = Cluster.build()
                .addContactPoints(uri.split("\\|"))
                .port(port)
                .serializer(new GryoMessageSerializerV1d0(GryoMapper.build().addRegistry(JanusGraphIoRegistry.getInstance())))
                .maxConnectionPoolSize(poolSize)
                .maxContentLength(10000000)
                .create();
        gts = AnonymousTraversalSource
                .traversal()
                .withRemote(DriverRemoteConnection.using(cluster));

Поскольку gts является threadSafe, я сохраняю gts в контексте c. Каждый поток использует один и тот же объект, и ни один из потоков не закрывает gts, вызывая gts.close () Каждый поток выполняет запрос, например: result = gts.V().has("foo","bar").valueMap().toList() Я не закрываю ни gts (graphTraversalSource), ни объект graphTraversal, который создается gts.V()

  • Должен ли я закрыть каждый объект graphTraversal, созданный из gts (graphTraversalSource).?
  • Когда я должен закрыть эти объекты?

1 Ответ

3 голосов
/ 09 января 2020

Для GraphTraversalSource необходимость вызова close() обусловлена ​​тем, как вы строите объект (например, «gts» в вашем случае). Javadocs на DriverRemoteConnection объясняет требования для close(). В вашем конкретном случае вы передаете объект Cluster, который вы сконструировали, DriverRemoteConnection.using(), что означает, что вы sh сами будете управлять отключением Cluster и, следовательно, вызов GraphTraversalSource.close() закроет только Client случаи, когда ваш GraphTraversalSource породил свою работу. Затем вам потребуется самостоятельно вызвать Cluster.close(), чтобы получить полное упорядоченное завершение работы и освобождение ресурсов.

Поведение для close() на GraphTraversal, порожденном от GraphTraversalSource, немного отличается в зависимости от от того, действительно ли вы удаленный или нет. В вашем случае вы используете удаленный обход и, следовательно, должны вызывать close() для устранения побочных эффектов на сервере (если обход генерировал какие-либо). Собирает ли ваш сервер побочные эффекты или нет для последующего извлечения, зависит от вашей реализации, но для большей части кода c лучше всего всегда делать это явно. Обратите внимание, что обходы порождаются над базами данных не удаленных (встроенных) графов, которые повторяются до завершения, так что hasNext() равен false, вызовет вызов close() и освободит ресурсы, удерживаемые графом. Например, вызов iterate() автоматически вызовет close().

Как примечание: поддержка сбора побочных эффектов, хранящихся на сервере, была удалена из протокола TinkerPop в 3.5.0, так что беспокойство вызывает уходящий - на серверах просто не будет больше побочных эффектов, хранящихся в памяти для последующего поиска.

...