janusgraph | JanusGraph : an open-source , distributed graph database | Graph Database library

Officially till Atlas 2.2.0 not support for authenticated Cassandra. But while building code we can update two files which are given in below PR and build Atlas. Which works as expected

https://github.com/apache/atlas/pull/67

The JanusGraph instances for a graph select one instance that maintains an ID pool manager. The JanusGraph reference documentation says the following about optimizing ID allocation:

ID Block Size

Each newly added vertex or edge is assigned a unique id. JanusGraph’s id pool manager acquires ids in blocks for a particular JanusGraph instance. The id block acquisition process is expensive because it needs to guarantee globally unique assignment of blocks. Increasing ids.block-size reduces the number of acquisitions but potentially leaves many ids unassigned and hence wasted. For transactional workloads the default block size is reasonable, but during bulk loading vertices and edges are added much more frequently and in rapid succession. Hence, it is generally advisable to increase the block size by a factor of 10 or more depending on the number of vertices to be added per machine.

Rule of thumb: Set ids.block-size to the number of vertices you expect to add per JanusGraph instance per hour.

Important: All JanusGraph instances MUST be configured with the same value for ids.block-size to ensure proper id allocation. Hence, be careful to shut down all JanusGraph instances prior to changing this value.

ID Acquisition Process

When id blocks are frequently allocated by many JanusGraph instances in parallel, allocation conflicts between instances will inevitably arise and slow down the allocation process. In addition, the increased write load due to bulk loading may further slow down the process to the point where JanusGraph considers it failed and throws an exception. There are three configuration options that can be tuned to avoid this.

1. ids.authority.wait-time configures the time in milliseconds the id pool manager waits for an id block application to be acknowledged by the storage backend. The shorter this time, the more likely it is that an application will fail on a congested storage cluster.

Rule of thumb: Set this to the sum of the 95th percentile read and write times measured on the storage backend cluster under load. Important: This value should be the same across all JanusGraph instances.

1. ids.renew-timeout configures the number of milliseconds JanusGraph’s id pool manager will wait in total while attempting to acquire a new id block before failing.

Rule of thumb: Set this value to be as large feasible to not have to wait too long for unrecoverable failures. The only downside of increasing it is that JanusGraph will try for a long time on an unavailable storage backend cluster.

In the middle of a traversal, a V() is applied to every traverser that has been created by the prior steps. Consider this example using the air-routes data set:

I believe what you are seeing is a special case condition with TinkerGraph where if you create two properties with the same key while creating the vertex as well, list cardinality is assumed. If you were to perform the same property additions on a vertex that already exists, single cardinality would be assumed and one would replace the other. For example:

Regarding question 1:
If not created explicitly, transactions are created automatically. From the JanusGraph reference docs:

Every graph operation in JanusGraph occurs within the context of a transaction. According to the TinkerPop’s transactional specification, each thread opens its own transaction against the graph database with the first operation (i.e. retrieval or mutation) on the graph.

A vertex retrieved during a transaction is stored in both the transaction cache and database cache. After closing the transaction the vertex is still in the database cache (but note that since janusgraph-0.5.x the database cache is disabled by default).

Regarding question 2:
Indeed, a JanusGraph instance cannot know about modifications to vertices in the transaction caches of other instances. Only after these transactions have been closed and persisted to the storage and index backends, other instances can read modified vertices from the the backends. This also means that caches in other JanusGraph instances can be out of date, so if you want to be sure that you have the latest data from the backends, you should start a new transaction and disable the database cache (default setting).

The vertex caches are private members of JanusGraph and nowhere exposed to the user (not even in the debug logging). Cache hits in a traversal are only visible from a fast (sub-millisecond) return time.

If data consistency between transactions or janusgraph instances matters to you, you can take a look at:

• https://docs.janusgraph.org/v0.4/advanced-topics/eventual-consistency/#data-consistency
• the new CacheVertex::refresh feature in janusgraph-0.6.0 (still undocumented).

The way to work with a traversal is by building it up iteratively first by concatenating the steps that you want to execute (like V(), has() and so on) and then to terminate the traversal with a terminal step like iterate() which will execute the traversal.

You however use two terminal steps in your example which doesn't work. First you execute HasNext() to verify that the vertex exists and then you try to modify its properties which you then want to execute via Iterate(). The traversal was however already evaluated and its Bytecode was sent to the server when you executed HasNext(). It is afterwards not possible any more to modulate the traversal object.

This becomes more clear when you try to do the same in the Gremlin Console:

The comment form HadoopMarc is the likely lead to solving your problem. You need to be sure sparql-gremlin is on your classpath for Gremlin Server when using this the way that you are in Gremlin Console. In other words, you are sending the Gremlin string of g = traversal(SparqlTraversalSource).withGraph(graph) to be executed on the server and the server doesn't know anything about SparqlTraversalSource if sparql-gremlin is not in its classpath.

To get this working via Gremlin Console and :remote (i.e. sending scripts) I would do try the following:

1. Get sparql-gremlin on your classpath for Gremlin Server (i.e. Janus Server). You can do that best with bin/gremlin-server.sh install org.apache.tinkerpop sparql-gremlin 3.4.12 (or whatever version you are using)
2. Start the server with a graph configured for JanusGraph in the server YAML file
3. Connect with Gremlin Console using :remote as you did in your example
4. Test to see if Gremlin Server picked up the package by sending just submitting a script of SparqlTraversalSource which should return the classname.
5. If the previous step worked you should be able to do: traversal(SparqlTraversalSource).withGraph(graph).sparql("SELECT ?....")

If you have that all working then a next step might be to configure a special traversal source in the Gremlin Server initialization script that is already setup with the SparqlTraversalSource so that you can just reference it from your scripts directly.

Good news, this got fixed in the upcoming v0.6.0 release of JanusGraph (already available as prerelease at https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.0).

See the mgmt.getIndexOnlyConstraint(indexName) method at: https://github.com/JanusGraph/janusgraph/blob/v0.6.0/janusgraph-core/src/main/java/org/janusgraph/core/schema/JanusGraphManagement.java

By default, when you connect to a Gremlin Server using one of the Gremlin clients and you ask for a vertex, what you get back is a reference vertex. A reference vertex just contains the ID and the label. To get some properties you need to include them using valueMap, elementMap, project etc. Alternatively you can configure the Gremlin Server to return all properties. The default is set this way to reduce the amount of data that gets sent back to a client.

Please see the documentation for further details.

https://tinkerpop.apache.org/docs/current/reference/#gremlin-applications

https://tinkerpop.apache.org/docs/current/reference/#_properties_of_elements

There is a link in that documentation to a post about why the decisions were made. For convenience, I am including that link here as well.

https://lists.apache.org/thread.html/e959e85d4f8b3d46d281f2742a6e574c7d27c54bfc52f802f7c04af3%40%3Cdev.tinkerpop.apache.org%3E