Date   

Re: 0.5.3 Upsert and RemoveRelation Issues

Boxuan Li
 

Hi,

Thanks for reporting and investigating! To help us understand more about the context, would you mind sharing an isolated code snippet that is runnable and can reproduce the error? I was trying to reproduce issue but failed to do so.

Thanks,
Boxuan

On Aug 6, 2022, at 1:49 AM, sammy.jia via lists.lfaidata.foundation <sammy.jia=gmail.com@...> wrote:

Hello, 

I am using Java and JanusGraph 0.5.3, but I am having issues with a specific snippet of code. The code upserts a vertex and then adds a Cardinality.single property to the upserted vertex, even if the vertex already has the correct property value. The code snippet is provided at the bottom of this message.

The code works fine for inserted vertices, but it generates an IllegalArgumentException for updated vertices. The exception is being generated by StandardJanusGraphTx.java's removeRelation method. After some debugging, I discovered that the exact same property step is being called twice for updated vertices. The first property method call uses removeRelation to delete the old property from the updated vertex. The second property method call then uses removeRelation to delete the exact same old property as the first method call (they share the same ID). Strangely, the old property still thinks it is in the 'loaded' state. Midway through removeRelation, the server realizes that that the property has already been deleted, updates the property's lifecycle to 'removed' at roughly StandardJanusGraphTx.java:595, and throws an exception at StandardJanusGraphTx.java:602.

P.S. In this specific case, I was replacing a property with the exact same value. Eg. the updated vertex already has a property called "prop3" with the value "value3", but I am calling property("prop3", "value3") anyways without checking the vertex's state.

I have three main questions:
1. Why is the property step being called twice?
2. Does JanusGraph allow you to update a Cardinality.single property twice? 
3. Why does removeRelation generate a generic IllegalArgumentException when we delete something that has already been deleted? Shouldn't it just output a log and exit the method?

---

GraphTraversal<Vertex, Vertex> graphTraversal = null;

for (….) {

    if (graphTraversal == null) {

        graphTraversal = graphTraversalSource.V().has("prop1", "value1").fold()

            .coalesce(__.unfold(),

                 __.addV("label")

                .property("prop1", "value1")

                .property("prop2", "value2"));

 

    } else {

        graphTraversal.V().hasLabel("label").has("prop1", "value1").fold()

            .coalesce(__.unfold(),

                __.addV("label")

                .property("prop1", "value1")

                .property("prop2", "value2"));

    }

    graphTraversal.property("prop3", "value3");  // this is somehow being called twice

}



0.5.3 Upsert and RemoveRelation Issues

sammy.jia@...
 

Hello, 

I am using Java and JanusGraph 0.5.3, but I am having issues with a specific snippet of code. The code upserts a vertex and then adds a Cardinality.single property to the upserted vertex, even if the vertex already has the correct property value. The code snippet is provided at the bottom of this message.

The code works fine for inserted vertices, but it generates an IllegalArgumentException for updated vertices. The exception is being generated by StandardJanusGraphTx.java's removeRelation method. After some debugging, I discovered that the exact same property step is being called twice for updated vertices. The first property method call uses removeRelation to delete the old property from the updated vertex. The second property method call then uses removeRelation to delete the exact same old property as the first method call (they share the same ID). Strangely, the old property still thinks it is in the 'loaded' state. Midway through removeRelation, the server realizes that that the property has already been deleted, updates the property's lifecycle to 'removed' at roughly StandardJanusGraphTx.java:595, and throws an exception at StandardJanusGraphTx.java:602.

P.S. In this specific case, I was replacing a property with the exact same value. Eg. the updated vertex already has a property called "prop3" with the value "value3", but I am calling property("prop3", "value3") anyways without checking the vertex's state.

I have three main questions:
1. Why is the property step being called twice?
2. Does JanusGraph allow you to update a Cardinality.single property twice? 
3. Why does removeRelation generate a generic IllegalArgumentException when we delete something that has already been deleted? Shouldn't it just output a log and exit the method?

---

GraphTraversal<Vertex, Vertex> graphTraversal = null;

for (….) {

    if (graphTraversal == null) {

        graphTraversal = graphTraversalSource.V().has("prop1", "value1").fold()

            .coalesce(__.unfold(),

                 __.addV("label")

                .property("prop1", "value1")

                .property("prop2", "value2"));

 

    } else {

        graphTraversal.V().hasLabel("label").has("prop1", "value1").fold()

            .coalesce(__.unfold(),

                __.addV("label")

                .property("prop1", "value1")

                .property("prop2", "value2"));

    }

    graphTraversal.property("prop3", "value3");  // this is somehow being called twice

}


Re: Incorrect result when lucene index is present

hadoopmarc@...
 
Edited

OK, I repeated the experiment and got "0 1" again, so I expand on what I did.

I use the janusgraph-0.6.2 full binary distribution and start cassandra and elasticsearch with:

$ bin/janusgraph.sh start

I leave the running Janusgraph Server unused and start a JanusGraph instance in the gremlin console with:
graph = JanusGraphFactory.open('conf/janusgraph-cql-es.properties')

Note that your code lines show a private properties file.

Best wishes,   Marc


Re: Incorrect result when lucene index is present

inverseintegral42@...
 

Hey Marc,

I actually just tested your example where p and q are of type Integer with cql and elasticsearch:

PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
graph = JanusGraphFactory.open(conf);

GraphTraversalSource g = graph.traversal();
JanusGraphManagement m = graph.openManagement();

VertexLabel l = m.makeVertexLabel("L").make();
PropertyKey p = m.makePropertyKey("p").dataType(Integer.class).make();
PropertyKey q = m.makePropertyKey("q").dataType(Integer.class).make();
m.buildIndex("someName", Vertex.class).addKey(p).addKey(q).indexOnly(l).buildMixedIndex("jgex");
m.commit();

g.addV("L").property("p", 1).next();
g.tx().commit();

System.out.println(g.V().hasLabel("L").has("q").count().next());
System.out.println(g.V().hasLabel("L").has("q", not(eq(2))).count().next());
But I get the output 0, 0 which is what I would expect. You wrote that you got the output 0, 1 though. Do you have any idea where this could come from?


Re: Incorrect result when lucene index is present

inverseintegral42@...
 

Dear Marc,

I will report the issue on GitHub in that case. Currently, I'm busy with a project that automatically identifies these bugs but in the near future I can definitely start submitting PRs for the issues that I found.


Re: Using ConfiguredGraphFactory from docker image

hadoopmarc@...
 
Edited

Thanks for bringing this up. Indeed, managing custom images is a barrier that you sometimes want to avoid. Can you give the runtime configuration of the standard image a try and report back where this approach possibly strands? Almost anyone wanting to confirm your need will have to test it for themselves!

Best wishes,     Marc


Re: Incorrect result when lucene index is present

hadoopmarc@...
 

Hi inverseintegral,

You have been quite succesful as a test driver, that is detecting easily reproducible issues!
The current issue seems more like an issue of undefined behaviour, rather than an issue related to Lucene or UUID objects.
I get the same behaviour when using cql and elasticsearch:

```
graph = JanusGraphFactory.open('conf/janusgraph-cql-es.properties')
g = graph.traversal();
m = graph.openManagement();

l = m.makeVertexLabel("L").make();
p = m.makePropertyKey("p").dataType(Integer.class).make();
q = m.makePropertyKey("q").dataType(Integer.class).make();
m.buildIndex("someName", Vertex.class).addKey(p).addKey(q).indexOnly(l).buildMixedIndex("search");
m.commit();

g.addV("L").property("p", 1).next();
g.tx().commit();

g.V().hasLabel("L").has("q").count()
// ==> 0
g.V().hasLabel("L").has("q", not(eq(2))).count()
// ==> 1
```
The CompositeIndex, though, has the same behaviour as the case without index (counts 0 and 0). The reference docs do not expand on the use of multiple property keys in an index after adding them.

Apparently, when querying a mixed index with a neq() predicate, it is not checked whether the associated property exists or is non-null in the index for that graph element.
You can make an issue, again, if you want. Any interest in providing a PR for any of the issues you found? I am sure people on https://lists.lfaidata.foundation/g/janusgraph-dev/topics will want to help you if you would get stuck in the PR process. See also https://docs.janusgraph.org/development/ .

I checked for related issue, but only https://github.com/JanusGraph/janusgraph/issues/2588 could be related.

Best wishes,   Marc


Using ConfiguredGraphFactory from docker image

cdburke@...
 

Is it possible to use the ConfiguredGaphFactory so that graphs can be created and deleted dynamically while still using the default docker image? I've been using it by manually copying a modified properties file into the container, which works but is inconvenient (and with the berkeleydb backend I've had to create fresh containers several times after e.g. dropping databases).

I know that some environment variables can be injected at runtime to select different backends etc., but it isn't clear if the backend properties can also be changed in that way. I assume I can build a custom local image if that's the only automated option for making changes to the .properties files, I'd just like to know that for sure before I establish our procedures.


Re: Lucene index inconsistency

inverseintegral42@...
 

Yes that's correct. Initially, I sent a mail to the mailing list but it took 2 weeks to show up, so in the meantime I made an account and directly created the topic.
I have reported the topic to the moderators so that they can delete this one if possible :)


Re: Lucene index inconsistency

hadoopmarc@...
 

I assume you reposted this inadvertenly? I saw you created issue https://github.com/JanusGraph/janusgraph/issues/3146  to document this inconvenience.
Thanks,

Marc


Lucene index inconsistency

Inverse Integral <inverseintegral42@...>
 

Hey everyone,

I'm currently running janusgraph-inmemory with janusgraph-lucence both version 0.6.2
And I'm experiencing strange behaviour when creating an index that contains an underscore in its name.
Whenever I run the following code:
PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
JanusGraph graph = JanusGraphFactory.open(conf);
String name = "some_name";

graph.tx().rollback();
JanusGraphManagement management = graph.openManagement();

management.makePropertyKey("name").dataType(String.class).make();
management.commit();

management = graph.openManagement();

management.buildIndex(name, Vertex.class)
.addKey(management.getPropertyKey("name"))
.buildMixedIndex("search");
management.commit();

ManagementSystem.awaitGraphIndexStatus(graph, name).
status(SchemaStatus.REGISTERED)
.call();

management = graph.openManagement();
management.updateIndex(management.getGraphIndex(name), SchemaAction.REINDEX).get();
management.commit();

management = graph.openManagement();
System.out.println(management.printIndexes());

graph.traversal().addV().property("name", "Test").next();
graph.tx().commit();

I get the following output:

INFO  o.j.g.d.management.ManagementSystem - Index update job successful for [some_name]
------------------------------------------------------------------------------------------------
Graph Index (Vertex)           | Type        | Unique    | Backing        | Key:           Status |
---------------------------------------------------------------------------------------------------
some_name                      | Mixed       | false     | search         | name:         ENABLED |
---------------------------------------------------------------------------------------------------
Graph Index (Edge)             | Type        | Unique    | Backing        | Key:           Status |
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
Relation Index (VCI)           | Type        | Direction | Sort Key       | Order    |     Status |
---------------------------------------------------------------------------------------------------

ERROR o.j.g.database.StandardJanusGraph - Error while committing index mutations for transaction [5] on index: search
org.janusgraph.core.JanusGraphException: Could not execute operation due to backend exception
at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:54)
at org.janusgraph.diskstorage.indexing.IndexTransaction.flushInternal(IndexTransaction.java:158)
at org.janusgraph.diskstorage.indexing.IndexTransaction.commit(IndexTransaction.java:139)
at org.janusgraph.diskstorage.BackendTransaction.commitIndexes(BackendTransaction.java:143)
at org.janusgraph.graphdb.database.StandardJanusGraph.commit(StandardJanusGraph.java:804)
at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.commit(StandardJanusGraphTx.java:1525)
at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph$GraphTransaction.doCommit(JanusGraphBlueprintsGraph.java:322)
at org.apache.tinkerpop.gremlin.structure.util.AbstractTransaction.commit(AbstractTransaction.java:104)
at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph$GraphTransaction.commit(JanusGraphBlueprintsGraph.java:300)
at Scratch.main(scratch.java:48)
Caused by: org.janusgraph.diskstorage.PermanentBackendException: Permanent exception while executing backend operation IndexMutation
at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:79)
at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:52)
... 9 common frames omitted
Caused by: java.lang.IllegalArgumentException: Invalid store name: some_name
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:217)
at org.janusgraph.diskstorage.lucene.LuceneIndex.getStoreDirectory(LuceneIndex.java:194)
at org.janusgraph.diskstorage.lucene.LuceneIndex.getWriter(LuceneIndex.java:216)
at org.janusgraph.diskstorage.lucene.LuceneIndex.mutateStores(LuceneIndex.java:289)
at org.janusgraph.diskstorage.lucene.LuceneIndex.mutate(LuceneIndex.java:275)
at org.janusgraph.diskstorage.indexing.IndexTransaction$1.call(IndexTransaction.java:161)
at org.janusgraph.diskstorage.indexing.IndexTransaction$1.call(IndexTransaction.java:158)
at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:66)
... 10 common frames omitted

Wouldn't it be better to disallow the creation of the index in the first place? After the creation all queries seem to fail with the same PermanentBackendException.
Also I don't quite understand why underscores are not allowed in index names. Maybe this is a limitation of Lucene


Incorrect result when lucene index is present

inverseintegral42@...
 

When I run the following code with janusgraph-inmemory and janusgraph-lucene both in version 0.6.2
PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
JanusGraph graph = JanusGraphFactory.open(conf);

GraphTraversalSource g = graph.traversal();
JanusGraphManagement m = graph.openManagement();

VertexLabel l = m.makeVertexLabel("L").make();
PropertyKey p = m.makePropertyKey("p").dataType(Short.class).make();
PropertyKey q = m.makePropertyKey("q").dataType(UUID.class).make();
m.buildIndex("someName", Vertex.class).addKey(p).addKey(q).indexOnly(l).buildMixedIndex("search");
m.commit();

g.addV("L").property("p", (short) 1).next();
g.tx().commit();

System.out.println(g.V().hasLabel("L").has("q").count().next());
System.out.println(g.V().hasLabel("L").has("q", not(eq(UUID.randomUUID()))).count().next());

I get the output
0
1

But I would expect the output to be
0
0

since there is no vertex with label L and property q. When I remove the index the result is correct.
I assume that this is because the UUID type is handled incorrectly.
Note that this only happens if the index is on both keys (p and q).

I'm using the following configuration:

gremlin.graph=org.janusgraph.core.JanusGraphFactory
storage.backend=inmemory
index.search.backend=lucene
index.search.directory=data/searchindex
schema.default=none

 


Re: Lucene index long overflow

hadoopmarc@...
 

OK, good catch, it is a bug. I had not recognized Long.MAX_VALUE in your query. The LuceneIndex class converts the neq to a range query and adds + 1 to the requested value without any check. The writer must have thought nobody would notice. It works for:
g.V().has("age", P.neq(9223372036854775806L))

If you want, you can report it as an issue.

Best wishes,   Marc


Re: Lucene index long overflow

inverseintegral42@...
 

Your example indeed seems to work fine. If you change the traversal as such:

g.V().has("age", P.neq(9223372036854775807L))

it should throw an exception. The neq predicate seems to be the problem here.


Re: Lucene index long overflow

hadoopmarc@...
 
Edited

I am not sure what the trouble is in your approach. Using variable names key and label might be problematic (it is in the Gremlin Console). Rather than building out your example, I chose to rework the GraphOfTheGodsFactory with a Long property index for use in the console. See below, this provides you with a working playground (tested on JanusGraph-0.5.3).




graph = JanusGraphFactory.open('conf/janusgraph-berkeleyje-lucene.properties')


management = graph.openManagement();
name = management.makePropertyKey("name").dataType(String.class).make();
nameIndex = management.buildIndex("name", Vertex.class).addKey(name).unique().buildCompositeIndex();
management.setConsistency(nameIndex, ConsistencyModifier.LOCK);
age = management.makePropertyKey("age").dataType(Long.class).make();
management.buildIndex("vertices", Vertex.class).addKey(age).buildMixedIndex("search");

time = management.makePropertyKey("time").dataType(Integer.class).make();
reason = management.makePropertyKey("reason").dataType(String.class).make();
place = management.makePropertyKey("place").dataType(Geoshape.class).make();
management.buildIndex("edges", Edge.class).addKey(reason).addKey(place).buildMixedIndex("search");

management.makeEdgeLabel("father").multiplicity(Multiplicity.MANY2ONE).make();
management.makeEdgeLabel("mother").multiplicity(Multiplicity.MANY2ONE).make();
battled = management.makeEdgeLabel("battled").signature(time).make();
management.buildEdgeIndex(battled, "battlesByTime", Direction.BOTH, Order.desc, time);
management.makeEdgeLabel("lives").signature(reason).make();
management.makeEdgeLabel("pet").make();
management.makeEdgeLabel("brother").make();

management.makeVertexLabel("titan").make();
management.makeVertexLabel("location").make();
management.makeVertexLabel("god").make();
management.makeVertexLabel("demigod").make();
management.makeVertexLabel("human").make();
management.makeVertexLabel("monster").make();

management.commit();

tx = graph.newTransaction();
// vertices

saturn = tx.addVertex(T.label, "titan", "name", "saturn", "age", 10000);
sky = tx.addVertex(T.label, "location", "name", "sky");
sea = tx.addVertex(T.label, "location", "name", "sea");
jupiter = tx.addVertex(T.label, "god", "name", "jupiter", "age", 5000);
neptune = tx.addVertex(T.label, "god", "name", "neptune", "age", 4500);
hercules = tx.addVertex(T.label, "demigod", "name", "hercules", "age", 30);
alcmene = tx.addVertex(T.label, "human", "name", "alcmene", "age", 45);
pluto = tx.addVertex(T.label, "god", "name", "pluto", "age", 4000);
nemean = tx.addVertex(T.label, "monster", "name", "nemean");
hydra = tx.addVertex(T.label, "monster", "name", "hydra");
cerberus = tx.addVertex(T.label, "monster", "name", "cerberus");
tartarus = tx.addVertex(T.label, "location", "name", "tartarus");

// edges

jupiter.addEdge("father", saturn);
jupiter.addEdge("lives", sky, "reason", "loves fresh breezes");
jupiter.addEdge("brother", neptune);
jupiter.addEdge("brother", pluto);

neptune.addEdge("lives", sea).property("reason", "loves waves");
neptune.addEdge("brother", jupiter);
neptune.addEdge("brother", pluto);

hercules.addEdge("father", jupiter);
hercules.addEdge("mother", alcmene);
hercules.addEdge("battled", nemean, "time", 1, "place", Geoshape.point(38.1f, 23.7f));
hercules.addEdge("battled", hydra, "time", 2, "place", Geoshape.point(37.7f, 23.9f));
hercules.addEdge("battled", cerberus, "time", 12, "place", Geoshape.point(39f, 22f));

pluto.addEdge("brother", jupiter);
pluto.addEdge("brother", neptune);
pluto.addEdge("lives", tartarus, "reason", "no fear of death");
pluto.addEdge("pet", cerberus);

cerberus.addEdge("lives", tartarus);

// commit the transaction to disk
tx.commit();

g = graph.traversal()
g.V().has("age", P.lt(9223372036854775807L))

gremlin> g.V().has("age", P.lt(9223372036854775807L))
==>v[4264]
==>v[12536]
==>v[8344]
==>v[8440]
==>v[8272]
==>v[4344]


Re: Lucene index long overflow

inverseintegral42@...
 

A similar problem occurs when using the following traversal:

graph.traversal()
.V()
.hasLabel("test")
.has("prop", P.neq(-9223372036854775808L))
.count()
.next();


Re: Unsatisfied Link Error - Jansi

Joe Obernberger
 

Turns out that I needed to set the java.io.tmpdir somewhere other than /tmp (assuming that's the default).  Not sure why exactly, but by setting JAVA_OPTIONS with:
-Djava.io.tmpdir=/some/place/else
Then gremlin loads OK.

-Joe

On 7/20/2022 3:51 PM, Joe Obernberger via lists.lfaidata.foundation wrote:
Getting this error when trying to run Gremlin on an AWS EC2 instance - exactly like:

https://issues.apache.org/jira/browse/TINKERPOP-2584?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17367398#comment-17367398

I'm using openjdk 11.0.13, but it looks like it's some sort of amazon version as it comes up as 1:11.0.13.0.8-1.amzn2.0.3 when doing a yum list installed.
Is there any workaround?
Thanks.

-Joe

--
This email has been checked for viruses by AVG.
https://www.avg.com


Unsatisfied Link Error - Jansi

Joe Obernberger
 

Getting this error when trying to run Gremlin on an AWS EC2 instance - exactly like:

https://issues.apache.org/jira/browse/TINKERPOP-2584?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17367398#comment-17367398

I'm using openjdk 11.0.13, but it looks like it's some sort of amazon version as it comes up as 1:11.0.13.0.8-1.amzn2.0.3 when doing a yum list installed.
Is there any workaround?
Thanks.

-Joe


--
This email has been checked for viruses by AVG.
https://www.avg.com


Lucene index long overflow

inverseintegral42@...
 

When I run the following code with janusgraph-inmemory and janusgraph-lucene both in version 0.6.2.

PropertiesConfiguration conf = ConfigurationUtil.loadPropertiesConfig("conf/test.properties");
JanusGraph graph = JanusGraphFactory.open(conf);

JanusGraphManagement m = graph.openManagement();
PropertyKey key = m.makePropertyKey("prop").dataType(Long.class).make();
VertexLabel label = m.makeVertexLabel("test").make();
m.buildIndex("propIndex", Vertex.class).addKey(key).indexOnly(label).buildMixedIndex("search");
m.commit();

graph.traversal()
.V()
.hasLabel("test")
.has("prop", P.neq(9223372036854775807L))
.count()
.next();


an unexpected exception is thrown:

Exception in thread "main" org.janusgraph.core.JanusGraphException: Could not execute operation due to backend exception
    at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:54)
    at org.janusgraph.diskstorage.BackendTransaction.executeRead(BackendTransaction.java:488)
    at org.janusgraph.diskstorage.BackendTransaction.indexQueryCount(BackendTransaction.java:431)
    at org.janusgraph.graphdb.database.IndexSerializer.queryCount(IndexSerializer.java:603)
    at org.janusgraph.graphdb.query.graph.MixedIndexCountQueryBuilder.executeTotals(MixedIndexCountQueryBuilder.java:61)
    at org.janusgraph.graphdb.tinkerpop.optimize.step.JanusGraphMixedIndexCountStep.processNextStart(JanusGraphMixedIndexCountStep.java:75)
    at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:135)
    at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:40)
    at org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:240)
    at Scratch.main(scratch.java:35)
Caused by: org.janusgraph.diskstorage.PermanentBackendException: Permanent exception while executing backend operation indexQueryCount
    at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:79)
    at org.janusgraph.diskstorage.util.BackendOperation.execute(BackendOperation.java:52)
    ... 9 more
Caused by: java.lang.ArithmeticException: long overflow
    at java.base/java.lang.Math.addExact(Math.java:848)
    at org.janusgraph.diskstorage.lucene.LuceneIndex.numericQuery(LuceneIndex.java:634)
    at org.janusgraph.diskstorage.lucene.LuceneIndex.convertQuery(LuceneIndex.java:766)
    at org.janusgraph.diskstorage.lucene.LuceneIndex.convertQuery(LuceneIndex.java:864)
    at org.janusgraph.diskstorage.lucene.LuceneIndex.queryCount(LuceneIndex.java:927)
    at org.janusgraph.diskstorage.indexing.IndexTransaction.queryCount(IndexTransaction.java:114)
    at org.janusgraph.diskstorage.BackendTransaction$7.call(BackendTransaction.java:434)
    at org.janusgraph.diskstorage.BackendTransaction$7.call(BackendTransaction.java:431)
    at org.janusgraph.diskstorage.util.BackendOperation.executeDirect(BackendOperation.java:66)
    ... 10 more

I would expect this query to run without any problem since the constant does not overflow.


Re: sorl janusgraph indexing with http basic authentication

Real Life Adventure
 

Thanks Marc for the Quick Update.

81 - 100 of 6666