Hi Boxuan,

Thank you for the response. I tried by forceClosing all management instances except the current one before setting "tx.log-tx". Management is getting updated with latest value, this is not the issue even without closing other instances. The issue is graph.getConfiguration().hasLogTransactions() is not getting refreshed through JanusGraphManagement property update. My understanding is logTransactions will be updated only through GraphDatabaseConfiguration:preLoadConfiguration which will be called only when we open graph instance JanusGraphFactory.open(config).I don't see any setter method to update logTransactions when we update JanusGraphManagement property. Because of this after updating JanusGraphManagement when we restart cluster it's invoking  GraphDatabaseConfiguration:preLoadConfiguration which is updating logTransactions value then.

Please correct me if I am missing anything and it'll be really helpful if any alternative approach to update logTransaction when we update Management property without restarting the cluster.

Thanks,
Radhika

Hi Mark,
Thanks for the suggestions.

Narrowed down the issue to JanusGraph's support for Azul Prime JDK 8, which generates nanosecond precision for Instant.now() API, as compared to the millisecond precision for OpenJDK 8. So the issue was resolved by applying the patch for https://github.com/JanusGraph/janusgraph/issues/1979.

Thanks!
Ronnie

On Tue, Aug 24, 2021 at 06:20 AM, <hadoopmarc@...> wrote:

with

Got it. I will try it soon. 

Thanks, Marc!

Shipeng

Hi Shipeng Qi,

The system that you use might be too small for the number of threads in the loading code. You can try to decrease the number of threads from 8 to 4 with:

private static ExecutorService pool = Executors.newFixedThreadPool(4);

Best wishes,    Marc

I suspect this is due to stale management instances. Check out https://developer.ibm.com/articles/janusgraph-tips-and-tricks-pt-2/#troubleshooting-indexes and see if it helps.

Hi there,

I am new to Janusgraph. I have some problems in loading data to Janusgraph with Cassandra CQL as storage backend.

When I tried to load Graph500 to Janusgraph, planning to run benchmark on it.  I found that the edges loaded to janusgraph were not complete, 67107183 edges loaded while 67108864 supposed. (Vertices loaded were complete)

The code and config I used is post as below.

The code I used is a benchmark by tigergraph:
- load vertex: https://github.com/gaolk/graph-database-benchmark/blob/master/benchmark/janusgraph/multiThreadVertexImporter.java
- load edge: https://github.com/gaolk/graph-database-benchmark/blob/master/benchmark/janusgraph/multiThreadEdgeImporter.java

The config I used is conf/janusgraph-cql.properties in Janusgraph 0.5.3 full (https://github.com/JanusGraph/janusgraph/releases/download/v0.5.3/janusgraph-full-0.5.3.zip)

cache.db-cache-clean-wait = 20

cache.db-cache-size = 0.5

cache.db-cache-time = 180000

cache.db-cache = true

gremlin.graph=org.janusgraph.core.JanusGraphFactory

storage.backend=cql

storage.batch-loading=true

storage.cql.keyspace=janusgraph 

storage.hostname=127.0.0.1

I got those exceptions when loading data.
Exception 1:

Caused by: java.util.concurrent.ExecutionException: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: /127.0.0.1:9042 (com.datastax.driver.core.exceptions.OperationTimedOutException: [/127.0.0.1:9042] Timed out waiting for server response))

        at com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)

        at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)

        at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)

        at io.vavr.control.Try.of(Try.java:62)

        at io.vavr.concurrent.FutureImpl.lambda$run$2(FutureImpl.java:199)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

Exception 2:

Caused by: org.janusgraph.diskstorage.TemporaryBackendException: Could not successfully complete backend operation due to repeated temporary exceptions after PT10S

        at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:100)

        at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:54)

        at org.janusgraph.diskstorage.BackendTransaction.executeRead(BackendTransaction.java:469)

        at org.janusgraph.diskstorage.BackendTransaction.indexQuery(BackendTransaction.java:395)

        at org.janusgraph.graphdb.query.graph.MultiKeySliceQuery.execute(MultiKeySliceQuery.java:52)

        at org.janusgraph.graphdb.database.IndexSerializer.query(IndexSerializer.java:515)

        at org.janusgraph.graphdb.util.SubqueryIterator.<init>(SubqueryIterator.java:66)

        ... 20 more

Caused by: org.janusgraph.diskstorage.TemporaryBackendException: Temporary failure in storage backend

        at io.vavr.API$Match$Case0.apply(API.java:3174)

        at io.vavr.API$Match.of(API.java:3137)

        at org.janusgraph.diskstorage.cql.CQLKeyColumnValueStore.lambda$static$0(CQLKeyColumnValueStore.java:123)

        at io.vavr.control.Try.getOrElseThrow(Try.java:671)

        at org.janusgraph.diskstorage.cql.CQLKeyColumnValueStore.getSlice(CQLKeyColumnValueStore.java:290)

        at org.janusgraph.diskstorage.keycolumnvalue.KCVSProxy.getSlice(KCVSProxy.java:76)

        at org.janusgraph.diskstorage.keycolumnvalue.cache.ExpirationKCVSCache.lambda$getSlice$1(ExpirationKCVSCache.java:91)

        at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4742)

        at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)

        at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2319)

I have found solution on google but got few things help. Could somebody help?


Best Regards,
Shipeng Qi

Hi Boxuan,For existing JanusGraph setup, I am updating tx.log-tx configuration by setting management system property as mentioned in https://docs.janusgraph.org/basics/configuration/#global-configuration
And I could see the configuration updated properly in JanusGraphManagement.

managementSystem.get("tx.log-tx"); => prints false
managementSystem.set("tx.log-tx", true);
managementSystem.commit();
managementSystem.get("tx.log-tx"); => prints true

But this change is not reflected for logTransactions in GraphDatabaseConfiguration:preLoadConfiguration. 

graph.getConfiguration().hasLogTransactions() => prints false

While transaction recovery using StandardTransactionLogProcessor it checks for the argument graph.getConfiguration().hasLogTransactions() which is not having latest config('tx.log-tx') updated in ManagementSystem.
To reflect the change, I had to restart cluster two times. Also since it's GLOBAL property I am not allowed to override using graph.configuration() and only available option is to update through ManagementSystem which is not updating logTransactions.

I would really appreciate your help on this.

Thanks,
Radhika

Thank you, this is exactly what I look for.

Hi Toom,

Do you want to ALWAYS make sure the vertex is indexed? If so and if you happen to use Elasticsearch, you can set 

index.[X].elasticsearch.bulk-refresh=wait_for

See https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-refresh.html.

Best,
Boxuan

Janus supports "properties of properties", ie. properties defined on other properties. How is this represented with graphml? Should I use nested elements like this

<node>
<data key="foo">
bar
<data key="xxx">yyy</data>
</data>
</node>

or should I use attributes like this?

<node>
<data key="foo" xxx="yyy">bar</data>
</node>

janusgraph-full includes Gremlin Server

What is the difference between janusgraph-<version>.zip and janusgraph-full-<version>.zip?

Hi Laura,

Your assumption about ordering of nodes and edges is correct, see the warning at: https://tinkerpop.apache.org/docs/current/reference/#graphml

For your use case it seems that you can simply edit the nodes and edges out of order and now and then save an ordered version of the graph using the sort function of your editor. If you do a lot of editing, it is probably more convenient to write a custom csv import script for networkx and then save as graphml.

Best wishes,    Marc

Hi Ronnie
No idea what is going on here, but just being pragmatic:

the bin/janusgraph.sh script starts Cassandra, Elasticsearch and Gremlin Server using the conf/janusgraph-cql-es.conf graph configuration. As you can check in the janusgraph distribution files, this config does not specify the graph.timestamps  property (so defaults to MICRO).

So some things to try:

• does your Cassandra cluster have custom settings for the timestamp type? Then you hit an existing janusgraph issue.
• does your system have a locale different than english-international and does changing the locale recover the issue? Then you discovered a janusgraph issue!
• does removing the graph.timestamps=MICRO line help? Note that you can only try this on a new graph, because this setting is FIXED.

Best wishes,    Marc

Sorry I'm asking to this list because I can't find this information anywhere else.
Is it possible to have an <edge> element nested inside a <node> element with graphml? And will Janus be able to read it correctly? Basically, instead of

<node id="1"></node>
<node id="2"></node>
<edge source="1" target="2"></edge>

I would like to use

<node id="1">
<edge target="2"></edge>
</node>
<node id="2"></node>

This would be very useful to me because I have a file (in graphml format) that I'm editing manually, and nesting edges will help me keep all the information "bundled" within a <node>; it would also reduce the verbosity by a lot. Unfortunately I have a feeling that this is not defined by the graphml spec, but I wonder if Janus can parse it?

Thank you Boxuan for the response. I will create a feature request.

Regards,
Radhika

Hi Radhika,

Unfortunately, there is no such API. If you are willing to dive into JanusGraph source code, you can modify StandardTransactionLogProcessor::fixSecondaryFailure method and build JanusGraph by yourself.

You are also welcome to create a feature request on GitHub issues. Probably we should allow users to register a callback method when recovery is done.

Best,
Boxuan

Hi Team,

I am using JanusGraphFactory.startTransactionRecovery to recover secondary failure entries.
We need to perform some other action once recovery is completed, I couldn't find any API to know the status of recovery.
Is there any way to know if the recovery of all the failure entries is completed.

I would appreciate you help.

Thanks,
Radhika

Hi,

Environment
- JanusGraph 0.5.3 on JDK: 1.8
- Backend: Cassandra 3.11.3 running on JDK 1.8

Warning and error during first time server startup

2021-08-17T22:26:20,861 - WARN  [main:o.j.d.l.c.ConsistentKeyLocker@510] - Skipping outdated lock on KeyColumn [k=0x 16-165-160-103-105- 30- 71-114- 97-112-104- 95- 78- 97-109-101- 95- 73-110-100-101-248, c=0x  0] with our rid ( 48- 97- 55- 50- 97- 97- 57- 57- 49- 56- 57- 56- 57- 45-115-104- 97-114-101-100-106- 97-110-117-115-103-114- 97-112-104- 48- 49- 45-112- 50- 55- 45-101-110-103- 45-105-110- 48- 51- 45-113-117- 97-108-121-115- 45- 99-111-109- 49) but mismatched timestamp (actual ts 2021-08-17T22:26:20.755981Z, expected ts 2021-08-17T22:26:20.755981926Z)

2021-08-17T22:26:20,863 - ERROR [main:o.j.g.d.StandardJanusGraph@724] - Could not commit transaction [1] due to storage exception in system-commit

Caused by: org.janusgraph.diskstorage.PermanentBackendException: Read 1 locks with our rid  48- 97- 55- 50- 97- 97- 57- 57- 49- 56- 57- 56- 57- 45-115-104- 97-114-101-100-106- 97-110-117-115-103-114- 97-112-104- 48- 49- 45-112- 50- 55- 45-101-110-103- 45-105-110- 48- 51- 45-113-117- 97-108-121-115- 45- 99-111-109- 49 but mismatched timestamps; no lock column contained our timestamp (2021-08-17T22:26:20.755981926Z)

at org.janusgraph.diskstorage.locking.consistentkey.ConsistentKeyLocker.checkSeniority(ConsistentKeyLocker.java:542)

at org.janusgraph.diskstorage.locking.consistentkey.ConsistentKeyLocker.checkSingleLock(ConsistentKeyLocker.java:468)

at org.janusgraph.diskstorage.locking.consistentkey.ConsistentKeyLocker.checkSingleLock(ConsistentKeyLocker.java:118)

at org.janusgraph.diskstorage.locking.AbstractLocker.checkLocks(AbstractLocker.java:351)

... 27 more

2021-08-17T22:26:20,864 - ERROR [main:o.a.t.g.s.u.ServerGremlinExecutor@87] - Could not invoke constructor on class org.janusgraph.graphdb.management.JanusGraphManager (defined by the 'graphManager' setting) with one argument of class Settings