janusgraph-users@lists.lfaidata.foundation

Home Messages Hashtags Subgroups Calendar

Expanded

Between

and

Re: berkeleyje and lucene NoSuchMethodError

queshaw

I am using gradle. The jars for lucene and and berkekeyje weren't installed in my local maven repository. So, my dependencies are:

jar files in my libs directory:

janusgraph-berkeleyje-0.6.2.jar

janusgraph-lucene-0.6.2.jar

then:

compileClasspath - Compile classpath for source set 'main'.

+--- org.janusgraph:janusgraph-core:0.6.2

| +--- org.janusgraph:janusgraph-driver:0.6.2

| | +--- org.apache.tinkerpop:gremlin-core:3.5.3 -> 3.6.1

| | | +--- org.apache.tinkerpop:gremlin-shaded:3.6.1

| | | +--- org.apache.tinkerpop:gremlin-language:3.6.1

| | | | +--- org.antlr:antlr4-runtime:4.9.1

| | | | +--- org.javatuples:javatuples:1.2

| | | | \--- org.apache.commons:commons-text:1.9

| | | | \--- org.apache.commons:commons-lang3:3.11

| | | +--- org.apache.commons:commons-configuration2:2.7

| | | | +--- org.apache.commons:commons-lang3:3.9 -> 3.11

| | | | +--- org.apache.commons:commons-text:1.8 -> 1.9 (*)

| | | | \--- commons-logging:commons-logging:1.2

| | | +--- commons-beanutils:commons-beanutils:1.9.4

| | | | +--- commons-logging:commons-logging:1.2

| | | | \--- commons-collections:commons-collections:3.2.2

| | | +--- commons-collections:commons-collections:3.2.2

| | | +--- org.apache.commons:commons-lang3:3.11

| | | +--- org.yaml:snakeyaml:1.27

| | | +--- com.carrotsearch:hppc:0.7.1 -> 0.8.2

| | | +--- com.jcabi:jcabi-manifests:1.2.1

| | | | \--- com.jcabi:jcabi-log:0.20.0

| | | | \--- org.mockito:mockito-core:3.4.6

| | | | +--- net.bytebuddy:byte-buddy:1.10.13

| | | | +--- net.bytebuddy:byte-buddy-agent:1.10.13

| | | | \--- org.objenesis:objenesis:2.6

| | | +--- net.objecthunter:exp4j:0.4.8

| | | +--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30

| | | \--- org.slf4j:jcl-over-slf4j:1.7.25

| | | \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30

| | +--- org.apache.tinkerpop:gremlin-driver:3.5.3 -> 3.6.1

| | | +--- org.apache.tinkerpop:gremlin-core:3.6.1 (*)

| | | +--- io.netty:netty-all:4.1.77.Final

| | | | +--- io.netty:netty-buffer:4.1.77.Final

| | | | +--- io.netty:netty-codec:4.1.77.Final

| | | | +--- io.netty:netty-codec-dns:4.1.77.Final

| | | | +--- io.netty:netty-codec-haproxy:4.1.77.Final

| | | | +--- io.netty:netty-codec-http:4.1.77.Final

| | | | +--- io.netty:netty-codec-http2:4.1.77.Final

| | | | +--- io.netty:netty-codec-memcache:4.1.77.Final

| | | | +--- io.netty:netty-codec-mqtt:4.1.77.Final

| | | | +--- io.netty:netty-codec-redis:4.1.77.Final

| | | | +--- io.netty:netty-codec-smtp:4.1.77.Final

| | | | +--- io.netty:netty-codec-socks:4.1.77.Final

| | | | +--- io.netty:netty-codec-stomp:4.1.77.Final

| | | | +--- io.netty:netty-codec-xml:4.1.77.Final

| | | | +--- io.netty:netty-common:4.1.77.Final

| | | | +--- io.netty:netty-handler:4.1.77.Final

| | | | +--- io.netty:netty-handler-proxy:4.1.77.Final

| | | | +--- io.netty:netty-resolver:4.1.77.Final

| | | | +--- io.netty:netty-resolver-dns:4.1.77.Final

| | | | +--- io.netty:netty-transport:4.1.77.Final

| | | | +--- io.netty:netty-transport-rxtx:4.1.77.Final

| | | | +--- io.netty:netty-transport-sctp:4.1.77.Final

| | | | +--- io.netty:netty-transport-udt:4.1.77.Final

| | | | +--- io.netty:netty-transport-classes-epoll:4.1.77.Final

| | | | +--- io.netty:netty-transport-native-unix-common:4.1.77.Final

| | | | +--- io.netty:netty-transport-classes-kqueue:4.1.77.Final

| | | | \--- io.netty:netty-resolver-dns-classes-macos:4.1.77.Final

| | | \--- org.apache.commons:commons-lang3:3.11

| | +--- org.apache.tinkerpop:gremlin-groovy:3.5.3

| | | +--- org.apache.tinkerpop:gremlin-core:3.5.3 -> 3.6.1 (*)

| | | +--- org.apache.ivy:ivy:2.4.0

| | | +--- org.codehaus.groovy:groovy:2.5.14

| | | +--- org.codehaus.groovy:groovy-groovysh:2.5.14

| | | | +--- org.codehaus.groovy:groovy-cli-picocli:2.5.14

| | | | +--- org.codehaus.groovy:groovy-console:2.5.14

| | | | | +--- org.codehaus.groovy:groovy-templates:2.5.14

| | | | | | \--- org.codehaus.groovy:groovy-xml:2.5.14

| | | | | +--- org.codehaus.groovy:groovy-cli-picocli:2.5.14 (*)

| | | | | \--- org.codehaus.groovy:groovy-swing:2.5.14

| | | | \--- jline:jline:2.14.6

| | | +--- org.codehaus.groovy:groovy-json:2.5.14

| | | +--- org.codehaus.groovy:groovy-jsr223:2.5.14

| | | +--- org.apache.commons:commons-lang3:3.11

| | | +--- org.mindrot:jbcrypt:0.4

| | | \--- com.github.ben-manes.caffeine:caffeine:2.3.1

| | +--- com.google.guava:guava:29.0-jre

| | | +--- com.google.guava:failureaccess:1.0.1

| | | +--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava

| | | +--- com.google.code.findbugs:jsr305:3.0.2

| | | +--- org.checkerframework:checker-qual:2.11.1

| | | +--- com.google.errorprone:error_prone_annotations:2.3.4

| | | \--- com.google.j2objc:j2objc-annotations:1.3

| | +--- org.noggit:noggit:0.8

| | +--- org.locationtech.spatial4j:spatial4j:0.8

| | +--- org.locationtech.jts:jts-core:1.17.0

| | +--- org.apache.commons:commons-text:1.9 (*)

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- org.apache.tinkerpop:tinkergraph-gremlin:3.5.3 -> 3.6.1

| | +--- org.apache.tinkerpop:gremlin-core:3.6.1 (*)

| | \--- org.apache.commons:commons-lang3:3.11

| +--- org.glassfish:javax.json:1.1.4

| +--- io.dropwizard.metrics:metrics-core:4.1.18

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- io.dropwizard.metrics:metrics-graphite:4.1.18

| | +--- io.dropwizard.metrics:metrics-core:4.1.18 (*)

| | +--- com.rabbitmq:amqp-client:5.11.0

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- io.dropwizard.metrics:metrics-jmx:4.1.18

| | +--- io.dropwizard.metrics:metrics-core:4.1.18 (*)

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- net.oneandone.reflections8:reflections8:0.11.7

| | \--- org.javassist:javassist:3.22.0-GA

| +--- commons-collections:commons-collections:3.2.2

| +--- commons-configuration:commons-configuration:1.10

| | +--- commons-lang:commons-lang:2.6

| | \--- commons-logging:commons-logging:1.1.1 -> 1.2

| +--- org.apache.commons:commons-configuration2:2.7 (*)

| +--- commons-io:commons-io:2.8.0

| +--- commons-codec:commons-codec:1.15

| +--- com.carrotsearch:hppc:0.8.2

| +--- com.boundary:high-scale-lib:1.0.6

| +--- com.google.code.findbugs:jsr305:3.0.2

| \--- org.slf4j:slf4j-api:1.7.30

+--- com.sleepycat:je:18.3.12

+--- org.apache.lucene:lucene-core:7.7.2

+--- org.apache.lucene:lucene-analyzers-common:7.7.2

| \--- org.apache.lucene:lucene-core:7.7.2

+--- org.apache.lucene:lucene-queryparser:7.7.2

| +--- org.apache.lucene:lucene-core:7.7.2

| +--- org.apache.lucene:lucene-queries:7.7.2

| \--- org.apache.lucene:lucene-sandbox:7.7.2

+--- org.apache.lucene:lucene-spatial:7.7.2

| \--- org.apache.lucene:lucene-core:7.7.2

+--- org.apache.lucene:lucene-spatial-extras:7.7.2

| +--- org.apache.lucene:lucene-core:7.7.2

| +--- org.apache.lucene:lucene-spatial3d:7.7.2

| +--- io.sgr:s2-geometry-library-java:1.0.0

| \--- org.locationtech.spatial4j:spatial4j:0.7 -> 0.8

+--- org.apache.tinkerpop:gremlin-core:3.6.1 (*)

+--- org.apache.tinkerpop:gremlin-driver:3.6.1 (*)

\--- org.apache.tinkerpop:tinkergraph-gremlin:3.6.1 (*)

compileOnly - Compile only dependencies for source set 'main'. (n)

No dependencies

default - Configuration for default artifacts. (n)

No dependencies

implementation - Implementation only dependencies for source set 'main'. (n)

+--- org.janusgraph:janusgraph-core:0.6.2 (n)

+--- unspecified (n)

+--- com.sleepycat:je:18.3.12 (n)

+--- org.apache.lucene:lucene-core:7.7.2 (n)

+--- org.apache.lucene:lucene-analyzers-common:7.7.2 (n)

+--- org.apache.lucene:lucene-queryparser:7.7.2 (n)

+--- org.apache.lucene:lucene-spatial:7.7.2 (n)

+--- org.apache.lucene:lucene-spatial-extras:7.7.2 (n)

+--- org.apache.tinkerpop:gremlin-core:3.6.1 (n)

+--- org.apache.tinkerpop:gremlin-driver:3.6.1 (n)

\--- org.apache.tinkerpop:tinkergraph-gremlin:3.6.1 (n)

mainSourceElements - List of source directories contained in the Main SourceSet. (n)

No dependencies

runtimeClasspath - Runtime classpath of source set 'main'.

+--- org.janusgraph:janusgraph-core:0.6.2

| +--- org.janusgraph:janusgraph-driver:0.6.2

| | +--- org.apache.tinkerpop:gremlin-core:3.5.3 -> 3.6.1

| | | +--- org.apache.tinkerpop:gremlin-shaded:3.6.1

| | | +--- org.apache.tinkerpop:gremlin-language:3.6.1

| | | | +--- org.antlr:antlr4-runtime:4.9.1

| | | | +--- org.javatuples:javatuples:1.2

| | | | \--- org.apache.commons:commons-text:1.9

| | | | \--- org.apache.commons:commons-lang3:3.11

| | | +--- org.apache.commons:commons-configuration2:2.7

| | | | +--- org.apache.commons:commons-lang3:3.9 -> 3.11

| | | | +--- org.apache.commons:commons-text:1.8 -> 1.9 (*)

| | | | \--- commons-logging:commons-logging:1.2

| | | +--- commons-beanutils:commons-beanutils:1.9.4

| | | | +--- commons-logging:commons-logging:1.2

| | | | \--- commons-collections:commons-collections:3.2.2

| | | +--- commons-collections:commons-collections:3.2.2

| | | +--- org.apache.commons:commons-lang3:3.11

| | | +--- org.yaml:snakeyaml:1.27

| | | +--- com.carrotsearch:hppc:0.7.1 -> 0.8.2

| | | +--- com.jcabi:jcabi-manifests:1.2.1

| | | | \--- com.jcabi:jcabi-log:0.20.0

| | | | \--- org.mockito:mockito-core:3.4.6

| | | | +--- net.bytebuddy:byte-buddy:1.10.13

| | | | +--- net.bytebuddy:byte-buddy-agent:1.10.13

| | | | \--- org.objenesis:objenesis:2.6

| | | +--- net.objecthunter:exp4j:0.4.8

| | | +--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30

| | | \--- org.slf4j:jcl-over-slf4j:1.7.25

| | | \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30

| | +--- org.apache.tinkerpop:gremlin-driver:3.5.3 -> 3.6.1

| | | +--- org.apache.tinkerpop:gremlin-core:3.6.1 (*)

| | | +--- io.netty:netty-all:4.1.77.Final

| | | | +--- io.netty:netty-buffer:4.1.77.Final

| | | | +--- io.netty:netty-codec:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | \--- io.netty:netty-resolver:4.1.77.Final

| | | | +--- io.netty:netty-codec-dns:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | \--- io.netty:netty-codec:4.1.77.Final (*)

| | | | +--- io.netty:netty-codec-haproxy:4.1.77.Final

| | | | +--- io.netty:netty-codec-http:4.1.77.Final

| | | | +--- io.netty:netty-codec-http2:4.1.77.Final

| | | | +--- io.netty:netty-codec-memcache:4.1.77.Final

| | | | +--- io.netty:netty-codec-mqtt:4.1.77.Final

| | | | +--- io.netty:netty-codec-redis:4.1.77.Final

| | | | +--- io.netty:netty-codec-smtp:4.1.77.Final

| | | | +--- io.netty:netty-codec-socks:4.1.77.Final

| | | | +--- io.netty:netty-codec-stomp:4.1.77.Final

| | | | +--- io.netty:netty-codec-xml:4.1.77.Final

| | | | +--- io.netty:netty-common:4.1.77.Final

| | | | +--- io.netty:netty-handler:4.1.77.Final

| | | | | +--- io.netty:netty-resolver:4.1.77.Final (*)

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | \--- io.netty:netty-codec:4.1.77.Final (*)

| | | | +--- io.netty:netty-handler-proxy:4.1.77.Final

| | | | +--- io.netty:netty-resolver:4.1.77.Final (*)

| | | | +--- io.netty:netty-resolver-dns:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-resolver:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | +--- io.netty:netty-codec:4.1.77.Final (*)

| | | | | +--- io.netty:netty-codec-dns:4.1.77.Final (*)

| | | | | \--- io.netty:netty-handler:4.1.77.Final (*)

| | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | +--- io.netty:netty-transport-rxtx:4.1.77.Final

| | | | +--- io.netty:netty-transport-sctp:4.1.77.Final

| | | | +--- io.netty:netty-transport-udt:4.1.77.Final

| | | | +--- io.netty:netty-transport-classes-epoll:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport-native-unix-common:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport:4.1.77.Final (*)

| | | | +--- io.netty:netty-transport-native-unix-common:4.1.77.Final (*)

| | | | +--- io.netty:netty-transport-classes-kqueue:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport-native-unix-common:4.1.77.Final (*)

| | | | +--- io.netty:netty-resolver-dns-classes-macos:4.1.77.Final

| | | | | +--- io.netty:netty-resolver-dns:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport-native-unix-common:4.1.77.Final (*)

| | | | +--- io.netty:netty-transport-native-epoll:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport-native-unix-common:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport-classes-epoll:4.1.77.Final (*)

| | | | +--- io.netty:netty-transport-native-kqueue:4.1.77.Final

| | | | | +--- io.netty:netty-buffer:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport:4.1.77.Final (*)

| | | | | +--- io.netty:netty-transport-native-unix-common:4.1.77.Final (*)

| | | | | \--- io.netty:netty-transport-classes-kqueue:4.1.77.Final (*)

| | | | \--- io.netty:netty-resolver-dns-native-macos:4.1.77.Final

| | | | \--- io.netty:netty-resolver-dns-classes-macos:4.1.77.Final (*)

| | | \--- org.apache.commons:commons-lang3:3.11

| | +--- org.apache.tinkerpop:gremlin-groovy:3.5.3

| | | +--- org.apache.tinkerpop:gremlin-core:3.5.3 -> 3.6.1 (*)

| | | +--- org.apache.ivy:ivy:2.4.0

| | | +--- org.codehaus.groovy:groovy:2.5.14

| | | +--- org.codehaus.groovy:groovy-groovysh:2.5.14

| | | | +--- org.codehaus.groovy:groovy-cli-picocli:2.5.14

| | | | +--- org.codehaus.groovy:groovy-console:2.5.14

| | | | | +--- org.codehaus.groovy:groovy-templates:2.5.14

| | | | | | \--- org.codehaus.groovy:groovy-xml:2.5.14

| | | | | +--- org.codehaus.groovy:groovy-cli-picocli:2.5.14 (*)

| | | | | \--- org.codehaus.groovy:groovy-swing:2.5.14

| | | | \--- jline:jline:2.14.6

| | | +--- org.codehaus.groovy:groovy-json:2.5.14

| | | +--- org.codehaus.groovy:groovy-jsr223:2.5.14

| | | +--- org.apache.commons:commons-lang3:3.11

| | | +--- org.mindrot:jbcrypt:0.4

| | | \--- com.github.ben-manes.caffeine:caffeine:2.3.1

| | +--- com.google.guava:guava:29.0-jre

| | | +--- com.google.guava:failureaccess:1.0.1

| | | +--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava

| | | +--- com.google.code.findbugs:jsr305:3.0.2

| | | +--- org.checkerframework:checker-qual:2.11.1

| | | +--- com.google.errorprone:error_prone_annotations:2.3.4

| | | \--- com.google.j2objc:j2objc-annotations:1.3

| | +--- org.noggit:noggit:0.8

| | +--- org.locationtech.spatial4j:spatial4j:0.8

| | +--- org.locationtech.jts:jts-core:1.17.0

| | +--- org.apache.commons:commons-text:1.9 (*)

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- org.apache.tinkerpop:tinkergraph-gremlin:3.5.3 -> 3.6.1

| | +--- org.apache.tinkerpop:gremlin-core:3.6.1 (*)

| | \--- org.apache.commons:commons-lang3:3.11

| +--- org.glassfish:javax.json:1.1.4

| +--- io.dropwizard.metrics:metrics-core:4.1.18

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- io.dropwizard.metrics:metrics-graphite:4.1.18

| | +--- io.dropwizard.metrics:metrics-core:4.1.18 (*)

| | +--- com.rabbitmq:amqp-client:5.11.0

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- io.dropwizard.metrics:metrics-jmx:4.1.18

| | +--- io.dropwizard.metrics:metrics-core:4.1.18 (*)

| | \--- org.slf4j:slf4j-api:1.7.30

| +--- net.oneandone.reflections8:reflections8:0.11.7

| | \--- org.javassist:javassist:3.22.0-GA

| +--- commons-collections:commons-collections:3.2.2

| +--- commons-configuration:commons-configuration:1.10

| | +--- commons-lang:commons-lang:2.6

| | \--- commons-logging:commons-logging:1.1.1 -> 1.2

| +--- org.apache.commons:commons-configuration2:2.7 (*)

| +--- commons-io:commons-io:2.8.0

| +--- commons-codec:commons-codec:1.15

| +--- com.carrotsearch:hppc:0.8.2

| +--- com.boundary:high-scale-lib:1.0.6

| +--- com.google.code.findbugs:jsr305:3.0.2

| \--- org.slf4j:slf4j-api:1.7.30

+--- com.sleepycat:je:18.3.12

+--- org.apache.lucene:lucene-core:7.7.2

+--- org.apache.lucene:lucene-analyzers-common:7.7.2

| \--- org.apache.lucene:lucene-core:7.7.2

+--- org.apache.lucene:lucene-queryparser:7.7.2

| +--- org.apache.lucene:lucene-core:7.7.2

| +--- org.apache.lucene:lucene-queries:7.7.2

| \--- org.apache.lucene:lucene-sandbox:7.7.2

+--- org.apache.lucene:lucene-spatial:7.7.2

| \--- org.apache.lucene:lucene-core:7.7.2

+--- org.apache.lucene:lucene-spatial-extras:7.7.2

| +--- org.apache.lucene:lucene-core:7.7.2

| +--- org.apache.lucene:lucene-spatial3d:7.7.2

| +--- io.sgr:s2-geometry-library-java:1.0.0

| \--- org.locationtech.spatial4j:spatial4j:0.7 -> 0.8

+--- org.apache.tinkerpop:gremlin-core:3.6.1 (*)

+--- org.apache.tinkerpop:gremlin-driver:3.6.1 (*)

\--- org.apache.tinkerpop:tinkergraph-gremlin:3.6.1 (*)

runtimeElements - Elements of runtime for main. (n)

No dependencies

runtimeOnly - Runtime only dependencies for source set 'main'. (n)

No dependencies

Thanks

Show quoted text

On Monday, August 22, 2022 8:24 AM, hadoopmarc@... wrote:

Probably, janusgraph and tinkerpop versions got mixed up. If you use maven, can you show the janusgraph dependencies you used in the pom.xml (and tinkerpop if present in the pom.xml).

Best wishes, Marc

Re: berkeleyje and lucene NoSuchMethodError

hadoopmarc@...

#6595

Probably, janusgraph and tinkerpop versions got mixed up. If you use maven, can you show the janusgraph dependencies you used in the pom.xml (and tinkerpop if present in the pom.xml).

Best wishes, Marc

berkeleyje and lucene NoSuchMethodError

queshaw

#6594

Hi,

I hope this is an appropriate question. This is my first attempt to use janusgraph. I got extra dependencies from the 0.6.2 source, without lucene and berkeleyce were not found. I'm using jdk 1.8.2 for both building and running a test program. I get this error:

java.lang.NoSuchMethodError: org.apache.tinkerpop.gremlin.structure.util.CloseableIterator.asCloseable(Ljava/util/Iterator;)Lorg/apache/tinkerpop/gremlin/structure/util/CloseableIterator;

at org.janusgraph.graphdb.util.CloseableIteratorUtils.<clinit>(CloseableIteratorUtils.java:28)

at org.janusgraph.graphdb.query.graph.GraphCentricQueryBuilder.lambda$iterables$1(GraphCentricQueryBuilder.java:240)

at com.google.common.collect.Iterables.isEmpty(Iterables.java:988)

at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.addProperty(StandardJanusGraphTx.java:915)

at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.addProperty(StandardJanusGraphTx.java:838)

at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.addProperty(StandardJanusGraphTx.java:834)

at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.makeSchemaVertex(StandardJanusGraphTx.java:970)

at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.makePropertyKey(StandardJanusGraphTx.java:989)

at org.janusgraph.graphdb.types.StandardPropertyKeyMaker.make(StandardPropertyKeyMaker.java:114)

at lnf.LoadGraph.load(LoadGraph.java:81)

at lnf.LoadGraph.go(LoadGraph.java:58)

at lnf.LoadGraph.main(LoadGraph.java:44)

The line in question is:

PropertyKey url = mgmt.makePropertyKey("url").dataType(String.class).make();

Do you have any idea what the problem could be?

Re: Janusgraph-full-0.6.1: how to fix "WARNING: Critical severity vulnerabilities were found with Log4j!"

hadoopmarc@...

#6593
Edited

Hi Yingjie,

The JanusGraph and TinkerPop code only explicitly depend on slfj4j, so you can choose the logging implementation. you want You can simply remove the log4j-1.2.17.jar from the lib folder of the janusgraph binary distribution or exclude it in the pom.xml of any project depending on janusgraph.
Note that janusgraph also ships with logback and provides a sample config in conf/logback.xml.

Best wishes, Marc

Janusgraph-full-0.6.1: how to fix "WARNING: Critical severity vulnerabilities were found with Log4j!"

Yingjie Li

#6592

Hello All,

I have run janusgraph all in one 0.6.1 (janusgraph-full-0.6.1) and have embeded cassandra and elastic search. It seems that the embeded log4j has security issues and the recomended fixes as as below. Any people have done this for their installation, what are the recommended fix ?

Thanks
Yingjie

1. Upgrade the affected product listed below to a version which includes a patched version of log4j – CISO requires all version 1.x and 2.x to be upgraded to version 2.17.1 or later.

2. If upgrade is not possible, the affected component must be uninstalled or deleted.

Re: 0.5.3 Upsert and RemoveRelation Issues

Boxuan Li

#6591

Thanks Sammy. Regarding your last question, I believe it’s a design choice to let user know something wrong happened.

Show quoted text

On Aug 7, 2022, at 2:11 AM, sammy.jia via lists.lfaidata.foundation <sammy.jia=gmail.com@...> wrote:

I tried to create a snippet but was unable to reproduce the error. I will have to consult with some people over the weekday. Apologies, creating the snippet may take a bit of time.

In the meantime, do you happen to know the answer to the last question? Is it simply a design choice, or would JanusGraph stop working properly if it exited the method without generating an exception?

Re: 0.5.3 Upsert and RemoveRelation Issues

sammy.jia@...

#6590

I tried to create a snippet but was unable to reproduce the error. I will have to consult with some people over the weekday. Apologies, creating the snippet may take a bit of time.

In the meantime, do you happen to know the answer to the last question? Is it simply a design choice, or would JanusGraph stop working properly if it exited the method without generating an exception?

Re: 0.5.3 Upsert and RemoveRelation Issues

Boxuan Li

#6589

Hi,

Thanks for reporting and investigating! To help us understand more about the context, would you mind sharing an isolated code snippet that is runnable and can reproduce the error? I was trying to reproduce issue but failed to do so.

Thanks,

Boxuan

Show quoted text

On Aug 6, 2022, at 1:49 AM, sammy.jia via lists.lfaidata.foundation <sammy.jia=gmail.com@...> wrote:

Hello,

I am using Java and JanusGraph 0.5.3, but I am having issues with a specific snippet of code. The code upserts a vertex and then adds a Cardinality.single property to the upserted vertex, even if the vertex already has the correct property value. The code snippet is provided at the bottom of this message.

The code works fine for inserted vertices, but it generates an IllegalArgumentException for updated vertices. The exception is being generated by StandardJanusGraphTx.java's removeRelation method. After some debugging, I discovered that the exact same property step is being called twice for updated vertices. The first property method call uses removeRelation to delete the old property from the updated vertex. The second property method call then uses removeRelation to delete the exact same old property as the first method call (they share the same ID). Strangely, the old property still thinks it is in the 'loaded' state. Midway through removeRelation, the server realizes that that the property has already been deleted, updates the property's lifecycle to 'removed' at roughly StandardJanusGraphTx.java:595, and throws an exception at StandardJanusGraphTx.java:602.

P.S. In this specific case, I was replacing a property with the exact same value. Eg. the updated vertex already has a property called "prop3" with the value "value3", but I am calling property("prop3", "value3") anyways without checking the vertex's state.

I have three main questions:
1. Why is the property step being called twice?
2. Does JanusGraph allow you to update a Cardinality.single property twice?
3. Why does removeRelation generate a generic IllegalArgumentException when we delete something that has already been deleted? Shouldn't it just output a log and exit the method?

---

GraphTraversal<Vertex, Vertex> graphTraversal = null;

for (….) {

if (graphTraversal == null) {

graphTraversal = graphTraversalSource.V().has("prop1", "value1").fold()

.coalesce(__.unfold(),

__.addV("label")

.property("prop1", "value1")

.property("prop2", "value2"));

} else {

graphTraversal.V().hasLabel("label").has("prop1", "value1").fold()

.coalesce(__.unfold(),

__.addV("label")

.property("prop1", "value1")

.property("prop2", "value2"));

}

graphTraversal.property("prop3", "value3"); // this is somehow being called twice

}

0.5.3 Upsert and RemoveRelation Issues

sammy.jia@...

#6588

Hello,

I am using Java and JanusGraph 0.5.3, but I am having issues with a specific snippet of code. The code upserts a vertex and then adds a Cardinality.single property to the upserted vertex, even if the vertex already has the correct property value. The code snippet is provided at the bottom of this message.

The code works fine for inserted vertices, but it generates an IllegalArgumentException for updated vertices. The exception is being generated by StandardJanusGraphTx.java's removeRelation method. After some debugging, I discovered that the exact same property step is being called twice for updated vertices. The first property method call uses removeRelation to delete the old property from the updated vertex. The second property method call then uses removeRelation to delete the exact same old property as the first method call (they share the same ID). Strangely, the old property still thinks it is in the 'loaded' state. Midway through removeRelation, the server realizes that that the property has already been deleted, updates the property's lifecycle to 'removed' at roughly StandardJanusGraphTx.java:595, and throws an exception at StandardJanusGraphTx.java:602.

P.S. In this specific case, I was replacing a property with the exact same value. Eg. the updated vertex already has a property called "prop3" with the value "value3", but I am calling property("prop3", "value3") anyways without checking the vertex's state.

I have three main questions:
1. Why is the property step being called twice?
2. Does JanusGraph allow you to update a Cardinality.single property twice?
3. Why does removeRelation generate a generic IllegalArgumentException when we delete something that has already been deleted? Shouldn't it just output a log and exit the method?

---

GraphTraversal<Vertex, Vertex> graphTraversal = null;

for (….) {

if (graphTraversal == null) {

graphTraversal = graphTraversalSource.V().has("prop1", "value1").fold()

.coalesce(__.unfold(),

__.addV("label")

.property("prop1", "value1")

.property("prop2", "value2"));

} else {

graphTraversal.V().hasLabel("label").has("prop1", "value1").fold()

.coalesce(__.unfold(),

__.addV("label")

.property("prop1", "value1")

.property("prop2", "value2"));

}

graphTraversal.property("prop3", "value3"); // this is somehow being called twice

}

Re: Incorrect result when lucene index is present

hadoopmarc@...

#6587
Edited

OK, I repeated the experiment and got "0 1" again, so I expand on what I did.

I use the janusgraph-0.6.2 full binary distribution and start cassandra and elasticsearch with:

$ bin/janusgraph.sh start

I leave the running Janusgraph Server unused and start a JanusGraph instance in the gremlin console with:
graph = JanusGraphFactory.open('conf/janusgraph-cql-es.properties')

Note that your code lines show a private properties file.

Best wishes, Marc

Re: Incorrect result when lucene index is present

inverseintegral42@...

#6586

Hey Marc,

I actually just tested your example where p and q are of type Integer with cql and elasticsearch:

PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
graph = JanusGraphFactory.open(conf);

GraphTraversalSource g = graph.traversal();
JanusGraphManagement m = graph.openManagement();

VertexLabel l = m.makeVertexLabel("L").make();
PropertyKey p = m.makePropertyKey("p").dataType(Integer.class).make();
PropertyKey q = m.makePropertyKey("q").dataType(Integer.class).make();
m.buildIndex("someName", Vertex.class).addKey(p).addKey(q).indexOnly(l).buildMixedIndex("jgex");
m.commit();

g.addV("L").property("p", 1).next();
g.tx().commit();

System.out.println(g.V().hasLabel("L").has("q").count().next());
System.out.println(g.V().hasLabel("L").has("q", not(eq(2))).count().next());

But I get the output 0, 0 which is what I would expect. You wrote that you got the output 0, 1 though. Do you have any idea where this could come from?

Re: Incorrect result when lucene index is present

inverseintegral42@...

#6585

Dear Marc,

I will report the issue on GitHub in that case. Currently, I'm busy with a project that automatically identifies these bugs but in the near future I can definitely start submitting PRs for the issues that I found.

Re: Using ConfiguredGraphFactory from docker image

hadoopmarc@...

#6584
Edited

Thanks for bringing this up. Indeed, managing custom images is a barrier that you sometimes want to avoid. Can you give the runtime configuration of the standard image a try and report back where this approach possibly strands? Almost anyone wanting to confirm your need will have to test it for themselves!

Best wishes, Marc

Re: Incorrect result when lucene index is present

hadoopmarc@...

#6583

Hi inverseintegral,

You have been quite succesful as a test driver, that is detecting easily reproducible issues!
The current issue seems more like an issue of undefined behaviour, rather than an issue related to Lucene or UUID objects.
I get the same behaviour when using cql and elasticsearch:

```
graph = JanusGraphFactory.open('conf/janusgraph-cql-es.properties')
g = graph.traversal();
m = graph.openManagement();

l = m.makeVertexLabel("L").make();
p = m.makePropertyKey("p").dataType(Integer.class).make();
q = m.makePropertyKey("q").dataType(Integer.class).make();
m.buildIndex("someName", Vertex.class).addKey(p).addKey(q).indexOnly(l).buildMixedIndex("search");
m.commit();

g.addV("L").property("p", 1).next();
g.tx().commit();

g.V().hasLabel("L").has("q").count()
// ==> 0
g.V().hasLabel("L").has("q", not(eq(2))).count()
// ==> 1
```
The CompositeIndex, though, has the same behaviour as the case without index (counts 0 and 0). The reference docs do not expand on the use of multiple property keys in an index after adding them.

Apparently, when querying a mixed index with a neq() predicate, it is not checked whether the associated property exists or is non-null in the index for that graph element.
You can make an issue, again, if you want. Any interest in providing a PR for any of the issues you found? I am sure people on https://lists.lfaidata.foundation/g/janusgraph-dev/topics will want to help you if you would get stuck in the PR process. See also https://docs.janusgraph.org/development/ .

I checked for related issue, but only https://github.com/JanusGraph/janusgraph/issues/2588 could be related.

Best wishes, Marc

Using ConfiguredGraphFactory from docker image

cdburke@...

#6582

Is it possible to use the ConfiguredGaphFactory so that graphs can be created and deleted dynamically while still using the default docker image? I've been using it by manually copying a modified properties file into the container, which works but is inconvenient (and with the berkeleydb backend I've had to create fresh containers several times after e.g. dropping databases).

I know that some environment variables can be injected at runtime to select different backends etc., but it isn't clear if the backend properties can also be changed in that way. I assume I can build a custom local image if that's the only automated option for making changes to the .properties files, I'd just like to know that for sure before I establish our procedures.

Re: Lucene index inconsistency

inverseintegral42@...

#6581

Yes that's correct. Initially, I sent a mail to the mailing list but it took 2 weeks to show up, so in the meantime I made an account and directly created the topic.
I have reported the topic to the moderators so that they can delete this one if possible :)

Re: Lucene index inconsistency

hadoopmarc@...

#6580

I assume you reposted this inadvertenly? I saw you created issue https://github.com/JanusGraph/janusgraph/issues/3146 to document this inconvenience.
Thanks,

Marc

Lucene index inconsistency

Inverse Integral <inverseintegral42@...>

#6579

Hey everyone,

I'm currently running janusgraph-inmemory with janusgraph-lucence both version 0.6.2
And I'm experiencing strange behaviour when creating an index that contains an underscore in its name.
Whenever I run the following code:

PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
JanusGraph graph = JanusGraphFactory.open(conf);
String name = "some_name";

graph.tx().rollback();
JanusGraphManagement management = graph.openManagement();

management.makePropertyKey("name").dataType(String.class).make();
management.commit();

management = graph.openManagement();

management.buildIndex(name, Vertex.class)
        .addKey(management.getPropertyKey("name"))
        .buildMixedIndex("search");
management.commit();

ManagementSystem.awaitGraphIndexStatus(graph, name).
        status(SchemaStatus.REGISTERED)
        .call();

management = graph.openManagement();
management.updateIndex(management.getGraphIndex(name), SchemaAction.REINDEX).get();
management.commit();

management = graph.openManagement();
System.out.println(management.printIndexes());

graph.traversal().addV().property("name", "Test").next();
graph.tx().commit();

I get the following output:

INFO  o.j.g.d.management.ManagementSystem - Index update job successful for [some_name]
------------------------------------------------------------------------------------------------
Graph Index (Vertex)           | Type        | Unique    | Backing        | Key:           Status |
---------------------------------------------------------------------------------------------------
some_name                      | Mixed       | false     | search         | name:         ENABLED |
---------------------------------------------------------------------------------------------------
Graph Index (Edge)             | Type        | Unique    | Backing        | Key:           Status |
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
Relation Index (VCI)           | Type        | Direction | Sort Key       | Order    |     Status |
---------------------------------------------------------------------------------------------------

ERROR o.j.g.database.StandardJanusGraph - Error while committing index mutations for transaction [5] on index: search
org.janusgraph.core.JanusGraphException: Could not execute operation due to backend exception
	at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:54)
	at org.janusgraph.diskstorage.indexing.IndexTransaction.flushInternal(IndexTransaction.java:158)
	at org.janusgraph.diskstorage.indexing.IndexTransaction.commit(IndexTransaction.java:139)
	at org.janusgraph.diskstorage.BackendTransaction.commitIndexes(BackendTransaction.java:143)
	at org.janusgraph.graphdb.database.StandardJanusGraph.commit(StandardJanusGraph.java:804)
	at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.commit(StandardJanusGraphTx.java:1525)
	at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph$GraphTransaction.doCommit(JanusGraphBlueprintsGraph.java:322)
	at org.apache.tinkerpop.gremlin.structure.util.AbstractTransaction.commit(AbstractTransaction.java:104)
	at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph$GraphTransaction.commit(JanusGraphBlueprintsGraph.java:300)
	at Scratch.main(scratch.java:48)
Caused by: org.janusgraph.diskstorage.PermanentBackendException: Permanent exception while executing backend operation IndexMutation
	at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:79)
	at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:52)
	... 9 common frames omitted
Caused by: java.lang.IllegalArgumentException: Invalid store name: some_name
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:217)
	at org.janusgraph.diskstorage.lucene.LuceneIndex.getStoreDirectory(LuceneIndex.java:194)
	at org.janusgraph.diskstorage.lucene.LuceneIndex.getWriter(LuceneIndex.java:216)
	at org.janusgraph.diskstorage.lucene.LuceneIndex.mutateStores(LuceneIndex.java:289)
	at org.janusgraph.diskstorage.lucene.LuceneIndex.mutate(LuceneIndex.java:275)
	at org.janusgraph.diskstorage.indexing.IndexTransaction$1.call(IndexTransaction.java:161)
	at org.janusgraph.diskstorage.indexing.IndexTransaction$1.call(IndexTransaction.java:158)
	at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:66)
	... 10 common frames omitted

Wouldn't it be better to disallow the creation of the index in the first place? After the creation all queries seem to fail with the same PermanentBackendException.

Also I don't quite understand why underscores are not allowed in index names. Maybe this is a limitation of Lucene

Incorrect result when lucene index is present

inverseintegral42@...

#6578

When I run the following code with janusgraph-inmemory and janusgraph-lucene both in version 0.6.2

PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
JanusGraph graph = JanusGraphFactory.open(conf);

GraphTraversalSource g = graph.traversal();
JanusGraphManagement m = graph.openManagement();

VertexLabel l = m.makeVertexLabel("L").make();
PropertyKey p = m.makePropertyKey("p").dataType(Short.class).make();
PropertyKey q = m.makePropertyKey("q").dataType(UUID.class).make();
m.buildIndex("someName", Vertex.class).addKey(p).addKey(q).indexOnly(l).buildMixedIndex("search");
m.commit();

g.addV("L").property("p", (short) 1).next();
g.tx().commit();

System.out.println(g.V().hasLabel("L").has("q").count().next());
System.out.println(g.V().hasLabel("L").has("q", not(eq(UUID.randomUUID()))).count().next());

I get the output
0
1

But I would expect the output to be
0
0

since there is no vertex with label L and property q. When I remove the index the result is correct.
I assume that this is because the UUID type is handled incorrectly.
Note that this only happens if the index is on both keys (p and q).

I'm using the following configuration:

gremlin.graph=org.janusgraph.core.JanusGraphFactory
storage.backend=inmemory
index.search.backend=lucene
index.search.directory=data/searchindex
schema.default=none

Re: Lucene index long overflow

hadoopmarc@...

#6577

OK, good catch, it is a bug. I had not recognized Long.MAX_VALUE in your query. The LuceneIndex class converts the neq to a range query and adds + 1 to the requested value without any check. The writer must have thought nobody would notice. It works for:
g.V().has("age", P.neq(9223372036854775806L))

If you want, you can report it as an issue.

Best wishes, Marc

141 - 160 of 6733

Home Hashtags Subgroups Calendar Terms