Can't see my vertex and edge from my Graph instance but able to see from other graph instance
up vote
2
down vote
favorite
Working on a proof of concept if I add vertex and edge using the Graph instance inside my application and then I query those sometimes the query result send me the vertex and edge and sometimes doesn't, but if I create a JUnit test pointing to the server I'm able to see the vertex and edge persisted. Same happen if I drop a vertex or a edge
What I'm missing?
============= Class to work with Vertex and Edge =================
public class JanusGraphRepository implements GraphRepository {
private Graph graph;
private GraphTraversalSource g;
public JanusGraphRepository(Graph janusGraph) {
this.graph = janusGraph;
this.g = graph.traversal();
}
@Override
public void dropE(Object id) {
g.E(id).drop().iterate();
g.tx().commit();
}
@Override
public void dropV(Object id) {
g.V(id).drop().iterate();
g.tx().commit();
}
@Override
public Vertex addV(final Object... keyValues) {
Vertex v = graph.addVertex(keyValues);
graph.tx().commit();
return v;
}
@Override
public Edge addE(String edgeLabel, Object fromVertex, Object toVertex,
Object... keyValues) {
Edge e = graph.vertices(fromVertex).next().addEdge(edgeLabel,
graph.vertices(toVertex).next(), keyValues);
graph.tx().commit();
return e;
}
}
======================== Code to get vertices and edges ======================
JanusGraphFactory.Builder config = JanusGraphFactory.build();
config.set("storage.backend", "cql");
config.set("storage.hostname", "10.2.1.134");
config.set("storage.cql.keyspace", "janusgraph");
config.set("index.search.backend", "elasticsearch");
config.set("index.search.hostname", "10.2.1.134");
// config.set("index.search.elasticsearch.client-only", "true");
// ip address where cassandra is installed
// config.set("storage.username", "cassandra");
// config.set("storage.password", "cassandra");
// config.set("storage.port", "8182");
// Get the instance of graph
JanusGraph graph = config.open();
graph.vertices().forEachRemaining(x -> {
System.out.println(x.id());
});
System.out.println("------ Edges -------");
graph.edges().forEachRemaining(x -> {
System.out.println(x.toString());
});
Thanks
cassandra graph-theory tinkerpop3 janusgraph
add a comment |
up vote
2
down vote
favorite
Working on a proof of concept if I add vertex and edge using the Graph instance inside my application and then I query those sometimes the query result send me the vertex and edge and sometimes doesn't, but if I create a JUnit test pointing to the server I'm able to see the vertex and edge persisted. Same happen if I drop a vertex or a edge
What I'm missing?
============= Class to work with Vertex and Edge =================
public class JanusGraphRepository implements GraphRepository {
private Graph graph;
private GraphTraversalSource g;
public JanusGraphRepository(Graph janusGraph) {
this.graph = janusGraph;
this.g = graph.traversal();
}
@Override
public void dropE(Object id) {
g.E(id).drop().iterate();
g.tx().commit();
}
@Override
public void dropV(Object id) {
g.V(id).drop().iterate();
g.tx().commit();
}
@Override
public Vertex addV(final Object... keyValues) {
Vertex v = graph.addVertex(keyValues);
graph.tx().commit();
return v;
}
@Override
public Edge addE(String edgeLabel, Object fromVertex, Object toVertex,
Object... keyValues) {
Edge e = graph.vertices(fromVertex).next().addEdge(edgeLabel,
graph.vertices(toVertex).next(), keyValues);
graph.tx().commit();
return e;
}
}
======================== Code to get vertices and edges ======================
JanusGraphFactory.Builder config = JanusGraphFactory.build();
config.set("storage.backend", "cql");
config.set("storage.hostname", "10.2.1.134");
config.set("storage.cql.keyspace", "janusgraph");
config.set("index.search.backend", "elasticsearch");
config.set("index.search.hostname", "10.2.1.134");
// config.set("index.search.elasticsearch.client-only", "true");
// ip address where cassandra is installed
// config.set("storage.username", "cassandra");
// config.set("storage.password", "cassandra");
// config.set("storage.port", "8182");
// Get the instance of graph
JanusGraph graph = config.open();
graph.vertices().forEachRemaining(x -> {
System.out.println(x.id());
});
System.out.println("------ Edges -------");
graph.edges().forEachRemaining(x -> {
System.out.println(x.toString());
});
Thanks
cassandra graph-theory tinkerpop3 janusgraph
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Working on a proof of concept if I add vertex and edge using the Graph instance inside my application and then I query those sometimes the query result send me the vertex and edge and sometimes doesn't, but if I create a JUnit test pointing to the server I'm able to see the vertex and edge persisted. Same happen if I drop a vertex or a edge
What I'm missing?
============= Class to work with Vertex and Edge =================
public class JanusGraphRepository implements GraphRepository {
private Graph graph;
private GraphTraversalSource g;
public JanusGraphRepository(Graph janusGraph) {
this.graph = janusGraph;
this.g = graph.traversal();
}
@Override
public void dropE(Object id) {
g.E(id).drop().iterate();
g.tx().commit();
}
@Override
public void dropV(Object id) {
g.V(id).drop().iterate();
g.tx().commit();
}
@Override
public Vertex addV(final Object... keyValues) {
Vertex v = graph.addVertex(keyValues);
graph.tx().commit();
return v;
}
@Override
public Edge addE(String edgeLabel, Object fromVertex, Object toVertex,
Object... keyValues) {
Edge e = graph.vertices(fromVertex).next().addEdge(edgeLabel,
graph.vertices(toVertex).next(), keyValues);
graph.tx().commit();
return e;
}
}
======================== Code to get vertices and edges ======================
JanusGraphFactory.Builder config = JanusGraphFactory.build();
config.set("storage.backend", "cql");
config.set("storage.hostname", "10.2.1.134");
config.set("storage.cql.keyspace", "janusgraph");
config.set("index.search.backend", "elasticsearch");
config.set("index.search.hostname", "10.2.1.134");
// config.set("index.search.elasticsearch.client-only", "true");
// ip address where cassandra is installed
// config.set("storage.username", "cassandra");
// config.set("storage.password", "cassandra");
// config.set("storage.port", "8182");
// Get the instance of graph
JanusGraph graph = config.open();
graph.vertices().forEachRemaining(x -> {
System.out.println(x.id());
});
System.out.println("------ Edges -------");
graph.edges().forEachRemaining(x -> {
System.out.println(x.toString());
});
Thanks
cassandra graph-theory tinkerpop3 janusgraph
Working on a proof of concept if I add vertex and edge using the Graph instance inside my application and then I query those sometimes the query result send me the vertex and edge and sometimes doesn't, but if I create a JUnit test pointing to the server I'm able to see the vertex and edge persisted. Same happen if I drop a vertex or a edge
What I'm missing?
============= Class to work with Vertex and Edge =================
public class JanusGraphRepository implements GraphRepository {
private Graph graph;
private GraphTraversalSource g;
public JanusGraphRepository(Graph janusGraph) {
this.graph = janusGraph;
this.g = graph.traversal();
}
@Override
public void dropE(Object id) {
g.E(id).drop().iterate();
g.tx().commit();
}
@Override
public void dropV(Object id) {
g.V(id).drop().iterate();
g.tx().commit();
}
@Override
public Vertex addV(final Object... keyValues) {
Vertex v = graph.addVertex(keyValues);
graph.tx().commit();
return v;
}
@Override
public Edge addE(String edgeLabel, Object fromVertex, Object toVertex,
Object... keyValues) {
Edge e = graph.vertices(fromVertex).next().addEdge(edgeLabel,
graph.vertices(toVertex).next(), keyValues);
graph.tx().commit();
return e;
}
}
======================== Code to get vertices and edges ======================
JanusGraphFactory.Builder config = JanusGraphFactory.build();
config.set("storage.backend", "cql");
config.set("storage.hostname", "10.2.1.134");
config.set("storage.cql.keyspace", "janusgraph");
config.set("index.search.backend", "elasticsearch");
config.set("index.search.hostname", "10.2.1.134");
// config.set("index.search.elasticsearch.client-only", "true");
// ip address where cassandra is installed
// config.set("storage.username", "cassandra");
// config.set("storage.password", "cassandra");
// config.set("storage.port", "8182");
// Get the instance of graph
JanusGraph graph = config.open();
graph.vertices().forEachRemaining(x -> {
System.out.println(x.id());
});
System.out.println("------ Edges -------");
graph.edges().forEachRemaining(x -> {
System.out.println(x.toString());
});
Thanks
cassandra graph-theory tinkerpop3 janusgraph
cassandra graph-theory tinkerpop3 janusgraph
edited Nov 7 at 9:01
Rebecca Nelson
7742520
7742520
asked Oct 30 at 3:36
kolokol13
111
111
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
Mutations in Cassandra are not guaranteed to be instantly visible.
I see that you are using the CQL storage backend for Janus, which tells me you are using a Cassandra node/cluster. In Cassandra, writes are required to propagate to each node, and might not happen immediately. It sounds like you might be experiencing this.
Especially in the case where a particular write needs to be passed along to the node that owns its index range, and subsequent reads end up reading from that node, it is possible to get into a situation where a write followed by an immediate read does not show the data that was just written.
The time that it takes for the write to appear depends on a variety of factors in
the Cassandra cluster; generally, it shouldn't take more than a few minutes even at very high scale, but this is not guaranteed. Cassandra prioritizes availability over the consistency of mutations. As long as the cluster remains online and operational, mutations will make it to all replicas within a cluster eventually, but not necessarily at the time that the write call returns. This behavior is known as eventual consistency.
In order to get around this, you must adjust your expectations; you cannot expect data that was just written to the cluster (and therefore JanusGraph when using Cassandra as a backend) to be immediately available.
If your use-case cannot work with Cassandra's model of consistency, I'd suggest taking a look at HBase or one of the other backends listed in the Storage Backends Section of the JanusGraph Manual.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
Mutations in Cassandra are not guaranteed to be instantly visible.
I see that you are using the CQL storage backend for Janus, which tells me you are using a Cassandra node/cluster. In Cassandra, writes are required to propagate to each node, and might not happen immediately. It sounds like you might be experiencing this.
Especially in the case where a particular write needs to be passed along to the node that owns its index range, and subsequent reads end up reading from that node, it is possible to get into a situation where a write followed by an immediate read does not show the data that was just written.
The time that it takes for the write to appear depends on a variety of factors in
the Cassandra cluster; generally, it shouldn't take more than a few minutes even at very high scale, but this is not guaranteed. Cassandra prioritizes availability over the consistency of mutations. As long as the cluster remains online and operational, mutations will make it to all replicas within a cluster eventually, but not necessarily at the time that the write call returns. This behavior is known as eventual consistency.
In order to get around this, you must adjust your expectations; you cannot expect data that was just written to the cluster (and therefore JanusGraph when using Cassandra as a backend) to be immediately available.
If your use-case cannot work with Cassandra's model of consistency, I'd suggest taking a look at HBase or one of the other backends listed in the Storage Backends Section of the JanusGraph Manual.
add a comment |
up vote
2
down vote
Mutations in Cassandra are not guaranteed to be instantly visible.
I see that you are using the CQL storage backend for Janus, which tells me you are using a Cassandra node/cluster. In Cassandra, writes are required to propagate to each node, and might not happen immediately. It sounds like you might be experiencing this.
Especially in the case where a particular write needs to be passed along to the node that owns its index range, and subsequent reads end up reading from that node, it is possible to get into a situation where a write followed by an immediate read does not show the data that was just written.
The time that it takes for the write to appear depends on a variety of factors in
the Cassandra cluster; generally, it shouldn't take more than a few minutes even at very high scale, but this is not guaranteed. Cassandra prioritizes availability over the consistency of mutations. As long as the cluster remains online and operational, mutations will make it to all replicas within a cluster eventually, but not necessarily at the time that the write call returns. This behavior is known as eventual consistency.
In order to get around this, you must adjust your expectations; you cannot expect data that was just written to the cluster (and therefore JanusGraph when using Cassandra as a backend) to be immediately available.
If your use-case cannot work with Cassandra's model of consistency, I'd suggest taking a look at HBase or one of the other backends listed in the Storage Backends Section of the JanusGraph Manual.
add a comment |
up vote
2
down vote
up vote
2
down vote
Mutations in Cassandra are not guaranteed to be instantly visible.
I see that you are using the CQL storage backend for Janus, which tells me you are using a Cassandra node/cluster. In Cassandra, writes are required to propagate to each node, and might not happen immediately. It sounds like you might be experiencing this.
Especially in the case where a particular write needs to be passed along to the node that owns its index range, and subsequent reads end up reading from that node, it is possible to get into a situation where a write followed by an immediate read does not show the data that was just written.
The time that it takes for the write to appear depends on a variety of factors in
the Cassandra cluster; generally, it shouldn't take more than a few minutes even at very high scale, but this is not guaranteed. Cassandra prioritizes availability over the consistency of mutations. As long as the cluster remains online and operational, mutations will make it to all replicas within a cluster eventually, but not necessarily at the time that the write call returns. This behavior is known as eventual consistency.
In order to get around this, you must adjust your expectations; you cannot expect data that was just written to the cluster (and therefore JanusGraph when using Cassandra as a backend) to be immediately available.
If your use-case cannot work with Cassandra's model of consistency, I'd suggest taking a look at HBase or one of the other backends listed in the Storage Backends Section of the JanusGraph Manual.
Mutations in Cassandra are not guaranteed to be instantly visible.
I see that you are using the CQL storage backend for Janus, which tells me you are using a Cassandra node/cluster. In Cassandra, writes are required to propagate to each node, and might not happen immediately. It sounds like you might be experiencing this.
Especially in the case where a particular write needs to be passed along to the node that owns its index range, and subsequent reads end up reading from that node, it is possible to get into a situation where a write followed by an immediate read does not show the data that was just written.
The time that it takes for the write to appear depends on a variety of factors in
the Cassandra cluster; generally, it shouldn't take more than a few minutes even at very high scale, but this is not guaranteed. Cassandra prioritizes availability over the consistency of mutations. As long as the cluster remains online and operational, mutations will make it to all replicas within a cluster eventually, but not necessarily at the time that the write call returns. This behavior is known as eventual consistency.
In order to get around this, you must adjust your expectations; you cannot expect data that was just written to the cluster (and therefore JanusGraph when using Cassandra as a backend) to be immediately available.
If your use-case cannot work with Cassandra's model of consistency, I'd suggest taking a look at HBase or one of the other backends listed in the Storage Backends Section of the JanusGraph Manual.
answered Nov 6 at 20:34
Rebecca Nelson
7742520
7742520
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53057023%2fcant-see-my-vertex-and-edge-from-my-graph-instance-but-able-to-see-from-other-g%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown