Could you please provide a ES mapping that was generated for this property?

For these kind of queries you need TEXTSTRING mapping. As an alternative you can create composite index to "equals" queries

Hm, in Janusgraph version 0.6.0 there is a different library used https://github.com/datastax/java-driver , is there any point to have the dependency on apache cassandra?

There is a java library dependency in Janusgraph "high-scale-lib" which is old and unsupported (last update happened 8 years back, see https://github.com/boundary/high-scale-lib). When Janusgraph is i

Looking at the changes in 0.6.0 I think this problem was just hidden in the previous version as resources were not released properly private void releaseTransaction() { -//TODO: release non crucial da

The issue can be reproduced within certain conditions, I cannot find a recipe to reproduce it on any environment We have a query of type g.inject((int) 1).union(...).limit(5L) We have several subqueri

I had a similar problem, how I solved it: mgmt.getGraphIndex('my_index_name').getIndexStatus(mgmt.getPropertyKey("property_i_ised")) ==>INSTALLED graph.getOpenTransactions() - > showed me all the open

Hi Marc, problem is that Janusgraph uses tokenised field for "neq" comparisons and non tokenised for "eq". For example for a property "x" tokenised field in ES will have the name "x" and non-tokenized

Hi Marc, something like this var index = janusGraphManagement. buildIndex("indexname", org.apache.tinkerpop.gremlin.structure.Vertex.class) var xproperty = janusGraphManagement.makePropertyKey("x").da

Janusgraph setup: Storage backend: Scylla 3 Indexing backend: Elasticsearch 6 JG version: 0.5.3 Steps to reproduce: 1) Create a vertex with two fields mapped in ES index as TEXTSTRING("x" and "y") 2)

After rolling back the PR I mentioned in the beginning of the topic we do not experience any issues. Even back then it was not "out of memory", but the process just ate one full core of CPU and never

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 lik

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 anot