Hi Boxuan Li We are using RF3. What I meant is that essentially the data for system_properties is going to a single partition. Due to RF3, this partition is replicated 3 times. Does this clarify? Than

Hi all Updates on this issue - We found that the periodic removal of system_properties (while the ingestion is running) leads to graph corruption (mentioned at high level at https://docs.janusgraph.or

Hi Marc I've submitted this as a bug https://github.com/JanusGraph/janusgraph/issues/2515 Thanks

Hi JG community We are facing a weird issue with Replication factor 3 with scylla DB as backend. - we are using index for looking up V in the graph - observation is that for many vertices with the sam

Hi @simone We were planning to segregate the static configurations from the runtime dynamic configurations (last update TS from client, etc.). AFAIK only the static configurations are required by the

In scylla grafana board, this issue is seen with high number of foreground read tasks.

Thank you folks for getting back. @Simone3, yes this issue comes out as read timeout from the shard holding the system_properties table (there is only 1 partition for system_properties unreplicated).

Hi all We are using janusgraph at zeotap at humongous scale (~70B V and 50B E) backed by scylla. Right now I am facing an issue in janusgraph_ids table, wherein there are large partitions created in t

Hi all - The interaction with the underlying KV store via janusgraph client hits the `system_properties` table with a range query where the key is `configuration` (key = 0x636f6e66696775726174696f6e)