I did not figure out the reason of the problem, but what is interesting - CPU does not recover even after an hour or two and the process continues reading from Scylla with pretty high speed. Looks

Thank you for reporting this bug! That's interesting. The one difference I see is that now the code performs `rs.iterator()` immediately (and not lazily as it was previously). That said, I didn't

Hello, I would like to ask the following: Is there any recommended way to perform Schema/Data migration? Thanks in advance, Nick.

Hi there! What you describe looks very interesting and is definitely not intended behavior. You mentioned my PR which seems to cause these troubles. That's quite interesting because this PR was

Hi Mladen, Having answered several questions about the JanusGraph InputFormats, I can confirm that many users encounter problems with the size of the input splits. This is the case in particular for

After some research I figured out that rolling back this PR https://github.com/JanusGraph/janusgraph/pull/2080/files# helps

JG 0.5.3(same on 0.5.2), cannot be reproduced on JG 0.3.2 Backend: scyllaDB Indexing backend: ElasticSearch Steps to reproduce: 1) Create a node with a composite index for the field "X" 2) Create

Hello Mladen, Yes, we have experienced this issue as well, although we weren't able to fix it. You solution sounds very interesting, could you share your enhacement as a PR (even

Hi Mladen, I wasn’t aware that the CqlInputFormat we’re using is considered legacy. Looks then like we should migrate to spark-cassandra-connector. Could you please create an issue on GitHub

Hi, Can you provide more info on how the fields in your example are indexed? E.g. composite or mixed, what are all indexes involving any of these fields. 「Patrick Streifel <prstreifel@...>」在

We are running into a JanusGraph bug where a traversal that should return a list of vertices is returning an empty list. Here is some background info: Using a JanusGraph Server with

Hey there! I've recently been working on some Apache Spark jobs for Janusgraph via hadoop-gremlin (as described on https://docs.janusgraph.org/advanced-topics/hadoop/) and encountered several issues.

Thank you very much everyone

It would only affect the use of JanusGraph+Elastic if you were offering it in an -as-a-Service (-aaS) offering, like a commercial DBaaS. In which case the SSPL would require you to commit back to the

Sounds normal to me. Note that setting query.batch=true might help a bit. Also note that the graph structure, in particular the number of repeat steps, is important. Finally, note that caching in the

If I am understanding correctly, this does not affect the usage of Elasticsearch in JanusGraph. Regarding AWS's decision, seems no additional configs/code changes are needed if someone wants to use

Hi All, I have a multi-level graph with total 800 vertices. When I run g.V(<id of parent>).repeat(out()).emit() for first time, it takes 300ms. In profile(), I could see RepeatStep takes most of the

Please also read the stance of Elasticsearch itself (because the AWS article did not link to it ): https://www.elastic.co/blog/license-change-clarification

Hi all, Since ES seems to have changed their licensing, what does this entail about the future usage of ES as a JanusGraph index

Analytical queries require a full table scan. Some people succeed in speeding up analytical queries on JanusGraph using OLAP, check the older questions on OLAP and SparkGraphComputer