How to specify config for gremlin-client?

[gregory-h]

Another question rather than an issue; I'm not sure if it pertains to Gremlin in general or to gremlin-client so apologies if I'm posting in the wrong place.

I'd like to define a Geo index and use it from gremlin client; my setup is the stock 1.0.0-hadoop1 release. Starting the server with an empty db I execute the following in gremlin console:

// define a _geo property and index
graph = TitanFactory.open('conf/titan-cassandra-es.properties')
mgmt = graph.openManagement()
mgmt.makePropertyKey('_geo').dataType(Geoshape.class).cardinality(Cardinality.SINGLE).make()
l = mgmt.getPropertyKey('_geo')
mgmt.buildIndex('byGeo', Vertex.class).addKey(l).buildMixedIndex("search")
mgmt.commit()

// test
g = graph.traversal()
g.addVertex(label, 'AP', '_geo', Geoshape.point(45, 50))
g.addVertex(label, 'AP', '_geo', Geoshape.point(45, 55))
g.addVertex(label, 'AP', '_geo', Geoshape.point(45, 60))
g.V().has('_geo', geoWithin(Geoshape.circle(45, 50, 50)))

The geo query succeeds with no warnings so I assume the index was found.

With the server processes still running I wrap the test portion above into a mocha script and issue the same queries via gremlin-client, but I receive

Error: No signature of method: org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource.addVertex() is applicable for argument types: (org.apache.tinkerpop.gremlin.structure.T$1, java.lang.String, java.lang.String, com.thinkaurelius.titan.core.attribute.Geoshape) values: [label, AP, _geo, point[45.0,50.0]](Error 597)

I assume the problem is that my gremlin-server is not using the same graph as the gremlin console, so I update my gremlin-server.yaml to open the graph described by conf/titan-cassandra-es.properties and restart, but after doing this much my test doesn't log anything and doesn't return.

I guess I'm still not clear about the relationship between the moving parts :)

Help appreciated.

[jbmusso]

There is an inconsistency in Titan v1.0.0 between the gremlin-server.yaml file and the corresponding .properties file so yes, you'll have to edit this and make sure that conf/titan-cassandra-es.properties is loaded (default setup).
Once this is fixed, what happens if you restart Titan (bin/titan.sh stop && bin/titan.sh start) and load sample data? Do you get any results from the console and from gremlin-javascript?

On the gremlin-javascript side, you only have to configure host and port to point to your Gremlin server instance (typically, localhost:8182).

[gregory-h]

Hi and thanks for the reply.

After setting gremlin-server.yaml to reference conf/titan-cassandra-es-properties and cycling the server using titan.sh stop / start, gremlin console finds the previously loaded data and uses the geo index in queries.

gremlin> g.V()
18:55:31 WARN com.thinkaurelius.titan.graphdb.transaction.StandardTitanTx - Query requires iterating over all vertices [()]. For better performance, use indexes
==>v[4240]
==>v[4312]
==>v[4176]
gremlin> g.V().has('_geo', geoWithin(Geoshape.circle(45, 50, 50)))
==>v[4176]
gremlin>

For my mocha test of the same two queries gremlin-client returns the following error on the g.V() statement:

Error: No such property: g for class: Script2 (Error 597)
  at GremlinClient.handleMessage (node_modules/gremlin-client/src/gremlinclient.js:84:35)
  at WebSocket.onMessage (node_modules/gremlin-client/node_modules/ws/lib/WebSocket.js:418:14)
  at Receiver.ontext (node_modules/gremlin-client/node_modules/ws/lib/WebSocket.js:816:10)
  at node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:477:18
  at Receiver.applyExtensions (node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:364:5)
  at node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:466:14
  at Receiver.flush (node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:340:3)
  at Receiver.opcodes.1.finish (node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:482:12)
  at Receiver.expectHandler (node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:457:31)
  at Receiver.add (node_modules/gremlin-client/node_modules/ws/lib/Receiver.js:95:24)
  at Socket.realHandler (node_modules/gremlin-client/node_modules/ws/lib/WebSocket.js:800:20)
  at readableAddChunk (_stream_readable.js:172:18)
  at Socket.Readable.push (_stream_readable.js:130:10)
  at TCP.onread (net.js:542:20)

[dmill-bz]

Is there a script defined in your gremlin-server.yaml file? (scripts section). g needs to be set via a script in order to be defined. You seem to do this manually in your console which is why it works there.

[gregory-h]

Aside from changing the graphs section to point to conf/titan-cassandra-es.properties my gremlin-server.yaml is stock, and there is a scripts section pointing to scripts/empty-sample.groovy, which sets g.

// conf/gremlin-server/gremlin-server.yaml
..
graphs: {
graph: conf/titan-cassandra-es.properties}
plugins:

• aurelius.titan
  scriptEngines: {
  gremlin-groovy: {
  imports: [java.lang.Math],
  staticImports: [java.lang.Math.PI],
  scripts: [scripts/empty-sample.groovy]},
  ..

// scripts/empty-sample.groovy
// define the default TraversalSource to bind queries to.
g = graph.traversal()

To rule out the possibility that my environment is not as I expect I downloaded the 1.0.0-hadoop1 release into a new folder, verified that there were no titan processes running, ran titan with the stock config using ./bin/titan.sh start and was able to run a simple query g.V().drop() via gremlin client.

However if I change gremlin-server.yaml in that folder as described above and cycle the server I encounter the same error with gremlin client when running g.V().drop() - Error: No such property: g for class: Script2 (Error 597)

I recall that when opening conf/titan-cassandra-es.properties in gremlin console it took quite awhile (like 20s); could there be some sort of race condition when gremlin-server is initializing from it?

Grasping at straws.

[dmill-bz]

I don't have a stock titan here right now but can you post the content of conf/titan-cassandra-es.properties? as I recall there were often missing graph definitions (in the stock distro)

[gregory-h]

Copied below. Also out of curiosity I tried the same test using a local build of titan with tinkerpop-3.2.0 incubating (thinkaurelius/titan#1312). This build has gremlin-server.yaml set to use cassandra-es.properties by default, and I am able to run queries against it using gremlin-client; unfortunately it doesn't appear to support list properties with gremlin-client so I can't proceed with it.

// titan-1.0.0-hadoop1/conf/titan-cassandra-es.properties

# Titan configuration sample: Cassandra & Elasticsearch over sockets
#
# This file connects to Cassandra and Elasticsearch services running
# on localhost over the Thrift API and the Elasticsearch native
# "Transport" API on their respective default ports.  The Cassandra
# and Elasticsearch services must already be running before starting
# Titan with this file.

# The primary persistence provider used by Titan.  This is required.  It
# should be set one of Titan's built-in shorthand names for its standard
# storage backends (shorthands: berkeleyje, cassandrathrift, cassandra,
# astyanax, embeddedcassandra, hbase, inmemory) or to the full package and
# classname of a custom/third-party StoreManager implementation.
#
# Default:    (no default value)
# Data Type:  String
# Mutability: LOCAL
storage.backend=cassandrathrift

# The hostname or comma-separated list of hostnames of storage backend
# servers.  This is only applicable to some storage backends, such as
# cassandra and hbase.
#
# Default:    127.0.0.1
# Data Type:  class java.lang.String[]
# Mutability: LOCAL
storage.hostname=127.0.0.1

# Whether to enable Titan's database-level cache, which is shared across
# all transactions. Enabling this option speeds up traversals by holding
# hot graph elements in memory, but also increases the likelihood of
# reading stale data.  Disabling it forces each transaction to
# independently fetch graph elements from storage before reading/writing
# them.
#
# Default:    false
# Data Type:  Boolean
# Mutability: MASKABLE
cache.db-cache = true

# How long, in milliseconds, database-level cache will keep entries after
# flushing them.  This option is only useful on distributed storage
# backends that are capable of acknowledging writes without necessarily
# making them immediately visible.
#
# Default:    50
# Data Type:  Integer
# Mutability: GLOBAL_OFFLINE
#
# Settings with mutability GLOBAL_OFFLINE are centrally managed in Titan's
# storage backend.  After starting the database for the first time, this
# file's copy of this setting is ignored.  Use Titan's Management System
# to read or modify this value after bootstrapping.
cache.db-cache-clean-wait = 20

# Default expiration time, in milliseconds, for entries in the
# database-level cache. Entries are evicted when they reach this age even
# if the cache has room to spare. Set to 0 to disable expiration (cache
# entries live forever or until memory pressure triggers eviction when set
# to 0).
#
# Default:    10000
# Data Type:  Long
# Mutability: GLOBAL_OFFLINE
#
# Settings with mutability GLOBAL_OFFLINE are centrally managed in Titan's
# storage backend.  After starting the database for the first time, this
# file's copy of this setting is ignored.  Use Titan's Management System
# to read or modify this value after bootstrapping.
cache.db-cache-time = 180000

# Size of Titan's database level cache.  Values between 0 and 1 are
# interpreted as a percentage of VM heap, while larger values are
# interpreted as an absolute size in bytes.
#
# Default:    0.3
# Data Type:  Double
# Mutability: MASKABLE
cache.db-cache-size = 0.25

# Connect to an already-running ES instance on localhost

# The indexing backend used to extend and optimize Titan's query
# functionality. This setting is optional.  Titan can use multiple
# heterogeneous index backends.  Hence, this option can appear more than
# once, so long as the user-defined name between "index" and "backend" is
# unique among appearances.Similar to the storage backend, this should be
# set to one of Titan's built-in shorthand names for its standard index
# backends (shorthands: lucene, elasticsearch, es, solr) or to the full
# package and classname of a custom/third-party IndexProvider
# implementation.
#
# Default:    elasticsearch
# Data Type:  String
# Mutability: GLOBAL_OFFLINE
#
# Settings with mutability GLOBAL_OFFLINE are centrally managed in Titan's
# storage backend.  After starting the database for the first time, this
# file's copy of this setting is ignored.  Use Titan's Management System
# to read or modify this value after bootstrapping.
index.search.backend=elasticsearch

# The hostname or comma-separated list of hostnames of index backend
# servers.  This is only applicable to some index backends, such as
# elasticsearch and solr.
#
# Default:    127.0.0.1
# Data Type:  class java.lang.String[]
# Mutability: MASKABLE
index.search.hostname=127.0.0.1

# The Elasticsearch node.client option is set to this boolean value, and
# the Elasticsearch node.data option is set to the negation of this value.
# True creates a thin client which holds no data.  False creates a regular
# Elasticsearch cluster node that may store data.
#
# Default:    true
# Data Type:  Boolean
# Mutability: GLOBAL_OFFLINE
#
# Settings with mutability GLOBAL_OFFLINE are centrally managed in Titan's
# storage backend.  After starting the database for the first time, this
# file's copy of this setting is ignored.  Use Titan's Management System
# to read or modify this value after bootstrapping.
index.search.elasticsearch.client-only=true

# Or start ES inside the Titan JVM
#index.search.backend=elasticsearch
#index.search.directory=../db/es
#index.search.elasticsearch.client-only=false
#index.search.elasticsearch.local-mode=true

[dmill-bz]

Yeah try adding this at the top of the file :

gremlin.graph=com.thinkaurelius.titan.core.TitanFactory

For some reason it was missing from the 1.0.0 dist.

[gregory-h]

Ah yes that's got it thanks Dylan; I see that at the top of the 3.2.0 build version of the same file as well.

Out of curiosity do you see anything wrong with the gremlin below? For some reason I can't build my geo index with this config; starting from an empty db running ./bin/titan.sh start and then ./bin/gremlin.sh

gremlin> graph = TitanFactory.open('conf/titan-cassandra-es.properties')
==>standardtitangraph[cassandrathrift:[127.0.0.1]]
gremlin> mgmt = graph.openManagement()
==>com.thinkaurelius.titan.graphdb.database.management.ManagementSystem@2443abd6
gremlin> mgmt.makePropertyKey('_geo').dataType(Geoshape.class).cardinality(Cardinality.SINGLE).make()
==>_geo
gremlin> l = mgmt.getPropertyKey('_geo')
==>_geo
gremlin> mgmt.buildIndex('byGeo', Vertex.class).addKey(l).buildMixedIndex("search")
==>byGeo
gremlin> mgmt.commit()
==>null
gremlin> g = graph.traversal()
==>graphtraversalsource[standardtitangraph[cassandrathrift:[127.0.0.1]], standard]
gremlin> g.addVertex(label, 'AP', '_geo', Geoshape.point(45, 50))
No signature of method: org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource.addVertex() is applicable for argument types: (org.apache.tinkerpop.gremlin.structure.T$1, java.lang.String, java.lang.String, com.thinkaurelius.titan.core.attribute.Geoshape) values: [label, AP, _geo, point[45.0,50.0]]
Display stack trace? [yN] 

[dmill-bz]

Yes addVertex() is a method of graph and not the traversal object g. So try graph.addVertex(...) instead.

Glad you got things working :)

[gregory-h]

Oh right of course.

Thanks for all your help with this stuff.

Unfortunately I'm still kinda stuck; I need gremlin 3.2 features and have been getting by with titan-1.0.0-hadoop1 and a standalone gremlin-server-3.2, but this combination appears to work only by accident.

I'd like to use the titan-1.1.0-hadoop2 local build but it doesnt support list properties;
#58

Any chance you can also help get me past that issue?

Thanks again
Greg

---

From: Dylan Millikin notifications@github.com
Sent: October 1, 2016 9:41:48 AM
To: jbmusso/gremlin-javascript
Cc: Gregory; Author
Subject: Re: [jbmusso/gremlin-javascript] How to specify config for gremlin-client? (#59)

Yes addVertex() is a method of graph and not the traversal object g. So try graph.addVertex(...) instead.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/59#issuecomment-250918913, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAW5DarrPq4Uq2C1LLjT_nJ0zHCIMVpvks5qvn88gaJpZM4KJEhX.