script in empty-sample.groovy is called twice
I have JanusGraph running as it's own process and remote to it from Gremlin. Since i'm learning, i create an in-memory graph in empty-sample.goovy when i start JanusGraph
g = graph.traversal()
rV = g.addV('r').property('name', 'r-name').next()
bV = g.addV('b').property('name', 'b-name').next()
lV = g.addV('l').property('name', 'l-name').next()
g.V(rV).addE('c').to(bV).property('name', 'r-b').next()
g.V(rV).addE('ht').to(lV).property('name', 'r-ht').next()
g.tx().commit()
System.out.println( ">>>>>> post tx commit" )
g.V().each( System.out::println )
This outputs 3 vertices as i would expect.
>>>>>> post tx commit
...
v[4224]
v[4256]
v[4272]
However, when i start Gremlin and :remote connect, it seems to run empty-sample.groovy again. Now i have duplicate vertices.
>>>>>> post tx commit
...
v[4224]
v[4256]
v[4272]
v[8368]
v[12464]
v[4296]
My yaml file has
scriptEngines: {
gremlin-groovy: {
plugins: { ...,
org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {files: [scripts/empty-sample.groovy]}}}}
If this is expected behaviour - run the script on JanusGraph startup and then again on each(?) remote Gremlin connection - how would/where would one initialise an in-memory graph?
Thanks.
5 Replies
Can you please share your full
empty-sample.groovy
and also show how you connect to JanusGraph Server from Gremlin Console?empty-sample.groovy
I've added a test in buildGraph as a workaround. Without the test, i get duplicate vertices
// an init script that returns a Map allows explicit setting of global bindings.
def globals = [:]
// defines a sample LifeCycleHook that prints some output to the Gremlin Server console.
// note that the name of the key in the "global" map is unimportant.
globals << [hook : [
onStartUp: { ctx ->
ctx.logger.info("Executed once at startup of Gremlin Server.")
},
onShutDown: { ctx ->
ctx.logger.info("Executed once at shutdown of Gremlin Server.")
}
] as LifeCycleHook]
System.out.println( ">>>>> mapping traversal sources" )
// define the default TraversalSource to bind queries to - this one will be named "g".
globals << [ g : graph.traversal(),
g_garden : gardengraph.traversal(),
g_pbr : pbrgraph.traversal()
]
System.out.println( ">>>>> mapped traversal sources" )
globals.values().forEach( System.out::println )
buildGraph()
void buildGraph()
{
g = graph.traversal()
if( g.V().hasNext() )
{
return
}
rV = g.addV('r').property('name', 'r-name').next()
bV = g.addV('b').property('name', 'b-name').next()
lV = g.addV('l').property('name', 'l-name').next()
g.V(rV).addE('c').to(bV).property('name', 'r-b').next()
g.V(rV).addE('ht').to(lV).property('name', 'r-ht').next()
g.tx().commit()
System.out.println( ">>>>>> post tx commit" )
g.V().each( System.out::println )
}
gremlin connection
:remote connect tinkerpop.server conf/remote.yaml session
:remote console
the duplicates are made on executing :remote console
remote.yaml
hosts: [localhost]
port: 8182
serializer: { className: org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1, config: { serializeResultToString: true }}
So, every time you execute
:remote connect
+ :remote console
, you get the vertices created again by the traversals in your buildGraph()
method from the empty-sample.groovy
?I haven't tried doing that more than once in the same session, but yes, when i execute :remote connect + :remote console, the vertices are created again as you describe above. I'll try connect+console multiple times in the same session and let you know if vertices are being created again each time.
I am wondering in general whether this intended behavior of Gremlin Server or not. I guess this way of loading scripts was not really intended to be used to initially load a graph, but I'm not 100% sure. You could ask this on the TinkerPop server as this is mostly a question about TinkerPop's Gremlin Server which JanusGraph is only extending. Maybe someone over there has more knowlege of this.
Apart from that, my advise would be to find a different way to initially create your graph. If you're using Docker, then you could use
/docker-entrypoint-initdb.d
as described here: https://docs.janusgraph.org/operations/container/#initialization