|
Re: Janusgraph-full-0.6.1: how to fix "WARNING: Critical severity vulnerabilities were found with Log4j!"
Hi Yingjie,
The JanusGraph and TinkerPop code only explicitly depend on slfj4j, so you can choose the logging implementation. you want You can simply remove the log4j-1.2.17.jar from the lib folder of the janusgraph binary distribution or exclude it in the pom.xml of any project depending on janusgraph. Note that janusgraph also ships with logback and provides a sample config in conf/logback.xml. Best wishes, Marc |
|
|
|
Janusgraph-full-0.6.1: how to fix "WARNING: Critical severity vulnerabilities were found with Log4j!"
Yingjie Li
Hello All,
I have run janusgraph all in one 0.6.1 (janusgraph-full-0.6.1) and have embeded cassandra and elastic search. It seems that the embeded log4j has security issues and the recomended fixes as as below. Any people have done this for their installation, what are the recommended fix ? Thanks Yingjie 1. Upgrade the affected product listed below to a version which includes a patched version of log4j – CISO requires all version 1.x and 2.x to be upgraded to version 2.17.1 or later.2. If upgrade is not possible, the affected component must be uninstalled or deleted. |
|
|
|
Re: 0.5.3 Upsert and RemoveRelation Issues
Boxuan Li
Thanks Sammy. Regarding your last question, I believe it’s a design choice to let user know something wrong happened.
toggle quoted message
Show quoted text
|
|
|
|
Re: 0.5.3 Upsert and RemoveRelation Issues
sammy.jia@...
I tried to create a snippet but was unable to reproduce the error. I will have to consult with some people over the weekday. Apologies, creating the snippet may take a bit of time.
In the meantime, do you happen to know the answer to the last question? Is it simply a design choice, or would JanusGraph stop working properly if it exited the method without generating an exception? |
|
|
|
Re: 0.5.3 Upsert and RemoveRelation Issues
Boxuan Li
Hi,
toggle quoted message
Show quoted text
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
|
|
|
|
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
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");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, |
|
|
|
Re: Using ConfiguredGraphFactory from docker image
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"); I get the following output: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"); I get the output gremlin.graph=org.janusgraph.core.JanusGraphFactory
|
|
|
|
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)) |
|
|
|
Re: Lucene index long overflow
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() |
|
|