Date   

Avoiding duplicate vertex creation using unique indices

Umesh Gade <er.umeshgade@...>
 

Hi All,
        To avoid a situation of duplicate vertex creation due to parallel transactions, we are using index uniqueness over property which defines uniqueness of vertex. As per doc, we need to specify lock on index and property. (https://docs.janusgraph.org/advanced-topics/eventual-consistency/)
mgmt.setConsistency(name, ConsistencyModifier.LOCK) // Ensures only one name per vertex mgmt.setConsistency(index, ConsistencyModifier.LOCK) // Ensures name uniqueness in the graph

As per observation, specifying lock only on index blocks parallel transaction commit which avoids duplicate vertex creation. We didn't see any behavior change with or without lock on property.

Can anybody help me understand the significance of lock on property i.e. name in above example? 
Any example scenario to understand the meaning of "Ensures only one name per vertex" ? 

--
Sincerely,
Umesh Gade


Re: Failed to connect to a Cassandra cluster's all nodes without default port

zhouyu74748585@...
 

Hi,
I am sorry to make you confused. I get the line number 220 from a .class file,  not a .java file.
the line number in java file is 246. you can read it from the screenshot
but I don't mean this line case the issue,just because  I this is a good position to set the port to replace the default port.


Re: Failed to connect to a Cassandra cluster's all nodes without default port

Boxuan Li
 

I am a bit confused here.


(NetworkUtil.isLocalConnection(hostnames[0])) ? Deployment.LOCAL : Deployment.REMOTE


Are we looking at the same line here?
On Jun 22, 2021, at 5:32 PM, zhouyu74748585@... wrote:

The janusgraph will try to connect with 192.168.223.3:9042

I find the codes in janusgraph-cql-0.5.3.jar,

the codes is:

 

final Builder builder = Cluster.builder()

        .addContactPointsWithPorts(contactPoints)

        .withClusterName(configuration.get(CLUSTER_NAME));

        //.withPort(configuration.get(CLUSTER_PORT));

 

in branch V0.5  fed8439

I append the last line to solve this problem,but it only work when all the host have same port;



Re: Count Query

Vinayak Bali
 

I have gone through the commit, I think that will help. To confirm we need to test it with the master branch as it has been not released yet. Earlier, we downloaded the full version from the releases page(janusgraph-full-0.5.2) and moved forward. I am not sure how I can test the queries on the master branch. Please share the setups or any document regarding the same. Thank you.


On Fri, Jun 18, 2021 at 11:59 PM <owner.mad.epa@...> wrote:
Could you check your query on master branch?Possibly this https://github.com/JanusGraph/janusgraph/commit/7550033d1746d0844bac79e3a8b85685c2c6c79d fix improve this type of query


Re: Failed to connect to a Cassandra cluster's all nodes without default port

Ronnie
 

Yes. We face same issue when using custom ports with C* backend. The first host:port in storage.hostname is processed correctly. For the remainder of  comma separated host:port, JanusGraph tried to connect to those servers with the default port of 9042. We had this problem since JanusGraph 0.4.x was hoping this would be fixed by 0.5.3, but this issue still exist.


Re: Failed to connect to a Cassandra cluster's all nodes without default port

zhouyu74748585@...
 

The janusgraph will try to connect with 192.168.223.3:9042

I find the codes in janusgraph-cql-0.5.3.jar,

the codes is:

 

final Builder builder = Cluster.builder()

        .addContactPointsWithPorts(contactPoints)

        .withClusterName(configuration.get(CLUSTER_NAME));

        //.withPort(configuration.get(CLUSTER_PORT));

 

in branch V0.5  fed8439

I append the last line to solve this problem,but it only work when all the host have same port;


Re: Failed to connect to a Cassandra cluster's all nodes without default port

Boxuan Li
 

What happens when you only use “192.168.223.3” as your storage.hostname, and don’t set storage.port?

I am also not sure about what version of line 220 you are looking at. What is the commit hash? You can also just copy the code snippet here.

「<zhouyu74748585@...>」在 2021年6月22日 週二,上午9:42 寫道:

Hi,
the version is 0.53,and the line is line 220 in org.janusgraph.diskstorage.cql.CQLStoreManager
The cluster builder's port is default 9042.
when I set one host,the logs are the same.if I set three hosts,janusgraph only chose one to connect to cassandra cluster。
janusgraph gets other ips from cluster's metadata.but use the default port 9042 in the local 
cluster object,then the local cluster try to connect to the host with correct ip and default port.
 


Re: Failed to connect to a Cassandra cluster's all nodes without default port

zhouyu74748585@...
 

Hi,
the version is 0.53,and the line is line 220 in org.janusgraph.diskstorage.cql.CQLStoreManager
The cluster builder's port is default 9042.
when I set one host,the logs are the same.if I set three hosts,janusgraph only chose one to connect to cassandra cluster。
janusgraph gets other ips from cluster's metadata.but use the default port 9042 in the local 
cluster object,then the local cluster try to connect to the host with correct ip and default port.
 


Re: Failed to connect to a Cassandra cluster's all nodes without default port

Boxuan Li
 

Hi,

I am not sure what code you think is problematic. Can you provide 1) your JanusGraph version, and 2) the specific line(s) that you believe a bug exists?

What happens if you only provide only ONE host:port in the “storage.hostname”? Do you still see the same log? I am asking because the log you provided comes from DataStax Driver, not JanusGraph. The DataStax driver tries to connect to the cluster via the entry points you provide, even though the entry points are not a complete or correct set of all hosts. The driver then fetches meta data from the cluster and prints logs like “New Cassandra host XX added”. Thus, I suspect not every host in your Cassandra cluster uses 9042 port.

On Jun 21, 2021, at 4:00 PM, zhouyu74748585@... wrote:

hi,
 all the nodes have the same port。one of the nodes can keep the correct port,  the others will be changed to 9042.
the code is in org.janusgraph.diskstorage.cql.CQLStoreManager
and in this method Cluster initializeCluster()

the cluster builder has a default port 9042,and finally return a cluster with port 9042, the port in configurations will not be use.



Re: EOL version components

kumkar.dev@...
 

Thanks Florian for sharing these details !

Best regards,
Dev


Re: EOL version components

rngcntr
 

Hi Dev,

you can follow the progress here: https://github.com/JanusGraph/janusgraph/pull/2672

There is no ETA, but we are planning to release 0.6.0 as soon as possible. It is currently blocked by a TinkerPop issue: https://issues.apache.org/jira/browse/TINKERPOP-2579

Best regards,
Florian


Re: EOL version components

kumkar.dev@...
 

Hi Boxuan,

If possible can you please share 0.6.0 tentative release date? This would help us in planning updates.

Thanks
Dev


Re: Failed to connect to a Cassandra cluster's all nodes without default port

zhouyu74748585@...
 

hi,
 all the nodes have the same port。one of the nodes can keep the correct port,  the others will be changed to 9042.
the code is in org.janusgraph.diskstorage.cql.CQLStoreManager
and in this method Cluster initializeCluster()

the cluster builder has a default port 9042,and finally return a cluster with port 9042, the port in configurations will not be use.


Re: Count Query

owner.mad.epa@...
 

Could you check your query on master branch?Possibly this https://github.com/JanusGraph/janusgraph/commit/7550033d1746d0844bac79e3a8b85685c2c6c79d fix improve this type of query


Re: Custom analyzer with traversal queries

florent@...
 

Thank you !

Currently, we have only a limited set of features to support from ES, so we are most likely going to wrap the Janus' text predicates.

All the best,
Flo


Re: Failed to connect to a Cassandra cluster's all nodes without default port

Boxuan Li
 

Hi,

Can you check your cassandra nodes’ configurations? It looks like some of your nodes are still using 9042 for native transport port.

Cheers,
Boxuan

「<zhouyu74748585@...>」在 2021年6月17日 週四,下午4:39 寫道:

Hello everyone, when I try to connect to a Cassandra cluster which's port is not default, just like this 

StandardJanusGraph graph = (StandardJanusGraph) JanusGraphFactory.build().set("storage.backend", "cql").
set("storage.hostname", "192.168.223.3:51705,192.168.223.4:51705,192.168.223.5:51705,").
open();
but when I start it,
only one node's is correct, the others' port change to 9042, the default one. so I can only connect to one node.
I try to fix this, but it only useful when all nodes' port are the same.if different node has different port.it will not work.
So I hope someone will have a good solution.


Re: Custom analyzer with traversal queries

Boxuan Li
 

Hi Flo,

Elasticsearch Index is only used when your query is a global query (a.k.a. graph-centric query in JanusGraph), i.e. look up vertices with conditions. `traversal.V().has(…)` is a global query.

On the other hand, `traversal().V(idx1, idx2, …).has(…)` is a vertex-centric query rather than global query. Elasticsearch is not involved, thus your custom analyzers are not used.

Your observations are valid. The documentation is not very clear indeed.

Unfortunately I don’t see any workaround here. Probably you could modify Text.java and build your own JanusGraph. You may also want to create a feature request to allow custom analyzers without indexing backends. Probably we could make Text.java pluggable (not sure if that’s possible).

Best regards,
Boxuan

On Jun 17, 2021, at 3:56 PM, florent@... wrote:

Hello everyone,


As it's my first post, I'd first thank you all for your work ! It has been pretty neat to discover all of the work !

We've started to investigate the use of custom analyzers in our schema (-> https://docs.janusgraph.org/v0.5/index-backend/field-mapping/#for-elasticsearch), where ES is used as an indexing backend.

From what I've seen, initial selections will indeed use the index (e.g. `traversal().V().has(...)`). However, it isn't always used, and sometimes the janusgraph implementation of the predicate is used (e.g. when `traversal().V(idx1, idx2, ...).has(...)`). In this latter case, it's the predicates as implemented here that are run. For text fields, it looks like a tokenization and lower-casing are perform by them directly.

I haven't seen mention of this case in the documentation. So, I'm wondering if my observations are valid.

If so, is there a way to force the usage of ES indices? An IDs query could be way to implement such feature (at least for ES).


All the best,
Flo


Re: EOL version components

Boxuan Li
 

Hi Kumkar,

There is no standard process. I would suggest creating a [Feature Request] type issue: https://github.com/JanusGraph/janusgraph/issues/new?assignees=&labels=&template=feature-request.md 

You may want to state which libraries are in EOL, and preferably link to their EOL statements/documentation. I recommend checking the dependency version on master branch first before reporting.

Best regards,
Boxuan

On Jun 17, 2021, at 9:57 PM, kumkar.dev@... wrote:

Thanks Boxuan this really helps !

Can you please help with pointers to create GitHub issue for any EOL version?

Thanks
Dev Kumkar


Re: EOL version components

kumkar.dev@...
 

Thanks Boxuan this really helps !

Can you please help with pointers to create GitHub issue for any EOL version?

Thanks
Dev Kumkar


Re: EOL version components

Boxuan Li
 

Hi Kumkar,

The incoming 0.6.0 release contains (but not limited to) the following updates:

hppc: 0.8.0
noggit: 0.8
commons-configuration2: 2.7
commons-lang3: 3.11

You are welcome to create a GitHub issue for any EOL version you observe that is still being used by JanusGraph.

Best regards,
Boxuan

On Jun 17, 2021, at 9:35 PM, kumkar.dev@... wrote:

Hello

We are using Janus 0.5.3 and there are some components which are either old or else EOL version being used.

Old version used:
  • hppc-0.7.1.jar
  • jcabi-log-0.14.jar
  • noggit-0.6.jar
EOL version used:
  • commons-collections-3.2.2.jar
  • commons-configuration-1.10.jar
  • commons-lang-2.6.jar
  • javapoet-1.8.0.jar
Are there any upcoming updates which could be shared here pointing when and which of these components would be updated?

Thanks
Dev Kumkar

681 - 700 of 6651