Date   

Re: Character case behaviour different with or without indices

Nigel Brown <ni...@...>
 

Elasticsearch 5.1.1


Re: Character case behaviour different with or without indices

tpr...@...
 

which indexing backend do you use ?


Le lundi 5 juin 2017 18:53:40 UTC+2, Nigel Brown a écrit :
I should point out that I am using a build from master 0.2.0. 


Indexes stuck in INSTALLED status

Brandon Dean <engr...@...>
 

I've been struggling with my indexes getting stuck in the INSTALLED status with no apparent way to get them out of that status.  After much frustration, I started with a completely fresh install of JanusGraph 0.1.1, left the configuration as is, and then followed the steps from the documentation exactly to create a new composite index.  I was able to successfully create my index and it moved into the REGISTERED status and then the ENABLED status after issuing a REINDEX command.

1490727 [gremlin-server-session-1] INFO  org.janusgraph.graphdb.database.management.GraphIndexStatusWatchemposite do not currently have status REGISTERED: name=ENABLED

I then attempted to follow the documentation to delete this same index using the following steps:

gremlin> :remote connect tinkerpop.server /opt/vdp/janus/conf/remote.yaml session
gremlin> :remote console
gremlin> m = graph.openManagement()
gremlin> i = m.getGraphIndex('byNameComposite')
gremlin> m.updateIndex(i, SchemaAction.DISABLE_INDEX).get()
gremlin> m.commit()


Rather than moving to a DISABLED state though, my index is now back in the INSTALLED state and I am unable to move it to REGISTERED or DISABLED.  I've tried issuing additional commands to DISABLE or even REGISTER the index but they all time out and the status never changes from INSTALLED.

gremlin> m = graph.openManagement()
gremlin> i = m.getGraphIndex('byNameComposite')
gremlin> i.getIndexStatus(m.getPropertyKey('name'))
==>INSTALLED
gremlin> m.rollback()
gremlin> m.updateIndex(i, SchemaAction.REMOVE_INDEX).get()
Update action [REMOVE_INDEX] cannot be invoked for index with status [INSTALLED]

I'm currently the only user on this server.  I've performed rollbacks just to be certain and insured that there are no other open instances.  Anytime I issue an awaitGraphIndexStatus it times out and the status never changes.  What's the proper way to get this index to move out of the INSTALLED status?  Alternatively, what might be blocking that from occuring if it is supposed to happen automatically?

gremlin> graph.getOpenTransactions()
==>standardjanusgraphtx[0x18489ed6]
gremlin> graph.tx().rollback()
==>null
gremlin> graph.getOpenTransactions()
==>standardjanusgraphtx[0x18489ed6]
gremlin> graph.openManagement().getOpenInstances()
==>0a7f01141301102-dcwidphiat002-edc-nam-gm-com1(current)
gremlin> graph.openManagement().awaitGraphIndexStatus(graph, 'byNameComposite').call()
Script evaluation exceeded the configured 'scriptEvaluationTimeout' threshold of 30000 ms or evaluation wa request [graph.openManagement().awaitGraphIndexStatus(graph, 'byNameComposite').call()]: sleep interrupte

Any help for the new guy (me) would be very much appreciated!


Re: Odd behavior with elasticsearch and metapropeties

Adam Holley <holl...@...>
 

I know meta-properties only support single value.  My question was, should it return an error when you have a property that is defined as cardinality SET or LIST and you're trying to use it in a meta-property.  Additionally, since meta-properties are not indexed, should it return an error if you're trying to use a property that you've indexed?


Re: Odd behavior with elasticsearch and metapropeties

Robert Dale <rob...@...>
 


Robert Dale

On Tue, Jun 6, 2017 at 12:53 AM, Adam Holley <holl...@...> wrote:
Here's the setup.
I have 4 property keys, all part of a Mixed Index.
- name_string, Cardinality.SINGLE, Mapping.STRING.asParameter
- meta_name_string, Cardinality.SINGLE, Mapping.STRING.asParameter
- name_list, Cardinality.LIST, Mapping.STRING.asParameter
- meta_name_list, Cardinality.LIST, Mapping.STRING.asParameter

I created a vertex with a name_string and name_list property.  Then added some meta properties using meta_name_string, and meta_name_list.

The first time I tried to commit, I received the following error:
[0]: index [janusgraph], type [basicIndex], id [388], message [ElasticsearchIllegalArgumentException[failed to execute script]; nested: ScriptException[dyoovy] disabled]; ]
I enabled script execution and was able to commit.  While the metaproperties were not indexed, I did see some additional entries in the name_list when querying the index directly.
e.g.:
From gremlin:
g.V().valueMap()
==> [name_list:[john, john doe, john]]

From elasticsearch:
_index: "janusgraph",
_type: "basicIndex",
_id: "388",
_score: 1,
_source: {
   name_list: [
      "john",
      "john doe",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john"
   ]
}

This may be a bad pattern, but should have I expected adding metaproperties with properties defined in the index to fail since they are not indexed?  Additionally, should trying to use a property with Cardinality != SINGLE, fail for metaproperties?  The additional items in the name_list in the index are not really a problem since I get the properties from gremlin, but it seems like it might be a problem.  Or am I doing something wrong when creating the index?

Thanks.
Adam.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Odd behavior with elasticsearch and metapropeties

david.c...@...
 

Hi,
Your ES does not allowed groovy script.
So you have to set "script.engine.groovy.inline.update" to "true" in the yaml of the ES conf.

David


Odd behavior with elasticsearch and metapropeties

Adam Holley <holl...@...>
 

Here's the setup.
I have 4 property keys, all part of a Mixed Index.
- name_string, Cardinality.SINGLE, Mapping.STRING.asParameter
- meta_name_string, Cardinality.SINGLE, Mapping.STRING.asParameter
- name_list, Cardinality.LIST, Mapping.STRING.asParameter
- meta_name_list, Cardinality.LIST, Mapping.STRING.asParameter

I created a vertex with a name_string and name_list property.  Then added some meta properties using meta_name_string, and meta_name_list.

The first time I tried to commit, I received the following error:
[0]: index [janusgraph], type [basicIndex], id [388], message [ElasticsearchIllegalArgumentException[failed to execute script]; nested: ScriptException[dyoovy] disabled]; ]
I enabled script execution and was able to commit.  While the metaproperties were not indexed, I did see some additional entries in the name_list when querying the index directly.
e.g.:
From gremlin:
g.V().valueMap()
==> [name_list:[john, john doe, john]]

From elasticsearch:
_index: "janusgraph",
_type: "basicIndex",
_id: "388",
_score: 1,
_source: {
   name_list: [
      "john",
      "john doe",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john",
      "john"
   ]
}

This may be a bad pattern, but should have I expected adding metaproperties with properties defined in the index to fail since they are not indexed?  Additionally, should trying to use a property with Cardinality != SINGLE, fail for metaproperties?  The additional items in the name_list in the index are not really a problem since I get the properties from gremlin, but it seems like it might be a problem.  Or am I doing something wrong when creating the index?

Thanks.
Adam.


Re: Who is using JanusGraph in production?

Misha Brukman <mbru...@...>
 

Great point! I welcome case studies and in-depth descriptions, but those take a significant effort to write as well as get approved by appropriate PR/Legal/etc. departments, so while I am always advocating for these, it's not always going to be possible.

In the meantime, here's one from CELUM (will be added shortly to the website): https://www.celum.com/en/graph-driven-and-reactive-architecture and I hope we'll be adding more of these in the future.

On Mon, Jun 5, 2017 at 2:46 PM, Michael Markieta <mark...@...> wrote:
It would be great if the current user list also said a little bit about how they use it. It's impossible to tell how FiNQ and Seeq are using JanusGraph. We would benefit from having case study like material for others to look at (in due time).

On Saturday, 27 May 2017 08:13:17 UTC-4, Jimmy wrote:
Great! Thank you for your work!

Misha Brukman <mb...@...>于2017年5月27日周六 上午5:29写道:
Hi Jimmy,

I started building a list of companies using JanusGraph in production; you can see the current list here: https://github.com/JanusGraph/janusgraph#users (and the logos at the bottom of http://janusgraph.org) and more additions are on the way.

They appear to be happy with JanusGraph, but I'll let them chime in if they want to provide any additional details.

BTW, if anyone else is a production user of JanusGraph, please get in touch with me and let's get you added on the list as well!

Misha
On Fri, Apr 7, 2017 at 4:03 AM, Jimmy <xul...@...> wrote:
Lovely and promising project! I want to know if anyone is using JanusGraph in production at present?Thanks!

--
You received this message because you are subscribed to the Google Groups "JanusGraph users list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Liu-Cheng Xu


Re: Who is using JanusGraph in production?

Michael Markieta <mark...@...>
 

It would be great if the current user list also said a little bit about how they use it. It's impossible to tell how FiNQ and Seeq are using JanusGraph. We would benefit from having case study like material for others to look at (in due time).


On Saturday, 27 May 2017 08:13:17 UTC-4, Jimmy wrote:
Great! Thank you for your work!

Misha Brukman <mb...@...>于2017年5月27日周六 上午5:29写道:
Hi Jimmy,

I started building a list of companies using JanusGraph in production; you can see the current list here: https://github.com/JanusGraph/janusgraph#users (and the logos at the bottom of http://janusgraph.org) and more additions are on the way.

They appear to be happy with JanusGraph, but I'll let them chime in if they want to provide any additional details.

BTW, if anyone else is a production user of JanusGraph, please get in touch with me and let's get you added on the list as well!

Misha
On Fri, Apr 7, 2017 at 4:03 AM, Jimmy <xul...@...> wrote:
Lovely and promising project! I want to know if anyone is using JanusGraph in production at present?Thanks!

--
You received this message because you are subscribed to the Google Groups "JanusGraph users list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Liu-Cheng Xu


Re: Character case behaviour different with or without indices

ni...@...
 

I should point out that I am using a build from master 0.2.0. 


Re: Is textRegex using search backends?

ni...@...
 

I should point out that I am using a build from master 0.2.0.


Is textRegex using search backends?

ni...@...
 

I have a text and string index in a graph and if I do a direct query on either of them, I can search for multiple tokens. (See below)

A textRegex query does not seem to use either of these, it returns slower and I can only search within tokens. How is the meant to work?

How do I make textRegex use the search index?
How do I debug the way janus finds the index backends?

gremlin> graph.indexQuery("process_nameTextKey", "v.*:*program file*").vertices().iterator().take(10).collect{it.getElement()}.collect{it.value('process_name')}

==>C:\Program Files\pdfViewer\pdfViewer.exe

==>C:\\Program Files\\Synaptics\\SynTP\\SynTPEnh.exe

==>C:\\Program Files\\SOLIDWORKS Corp\\eDrawings X64 Edition\\eDrawings.exe

==>C:\\Program Files (x86)\\nxlog\\nxlog.exe

==>C:\\Program Files\\CCleaner\\CCleaner.exe

==>C:\\Program Files (x86)\\CyberLink\\YouCam6\\CLWFLService6.exe

==>C:\\Program Files (x86)\\airtel\\UpdateDog\\LiveUpd.exe

==>C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe

==>C:\\Program Files (x86)\\Adobe\\Reader 10.0\\Reader\\reader_sl.exe

==>C:\\Program Files (x86)\\Dell\\VideoStage\\UserAgent.exe

gremlin> graph.indexQuery("process_nameStringKey", "v.*:*program file*").vertices().iterator().take(10).collect{it.getElement()}.collect{it.value('process_name')}

==>C:\Program Files\pdfViewer\pdfViewer.exe

==>C:\\Program Files\\Synaptics\\SynTP\\SynTPEnh.exe

==>C:\\Program Files\\SOLIDWORKS Corp\\eDrawings X64 Edition\\eDrawings.exe

==>C:\\Program Files (x86)\\nxlog\\nxlog.exe

==>C:\\Program Files\\CCleaner\\CCleaner.exe

==>C:\\Program Files (x86)\\CyberLink\\YouCam6\\CLWFLService6.exe

==>C:\\Program Files (x86)\\airtel\\UpdateDog\\LiveUpd.exe

==>C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe

==>C:\\Program Files (x86)\\Adobe\\Reader 10.0\\Reader\\reader_sl.exe

==>C:\\Program Files (x86)\\Dell\\VideoStage\\UserAgent.exe

gremlin> g.E().has('process_name', textRegex( 'program file')).properties()

gremlin> g.E().has('process_name', textRegex( '.*program file.*')).properties()

gremlin> g.E().has('process_name', textContainsRegex( '.*program file.*')).properties()

gremlin> mgmt = graph.openManagement()

==>org.janusgraph.graphdb.database.management.ManagementSystem@281b2dfd

gremlin> mgmt.getGraphIndex('process_nameStringKey').getProperties()

==>unique=false

==>indexedElement=interface org.janusgraph.core.JanusGraphVertex

==>class=class org.janusgraph.graphdb.database.management.JanusGraphIndexWrapper

==>fieldKeys=[Lorg.janusgraph.core.PropertyKey;@1fb2eec

==>mixedIndex=true

==>baseIndex=process_nameStringKey

==>backingIndex=search

==>compositeIndex=false

gremlin> mgmt.getGraphIndex('process_nameTextKey').getProperties()

==>unique=false

==>indexedElement=interface org.janusgraph.core.JanusGraphVertex

==>class=class org.janusgraph.graphdb.database.management.JanusGraphIndexWrapper

==>fieldKeys=[Lorg.janusgraph.core.PropertyKey;@22f02996

==>mixedIndex=true

==>baseIndex=process_nameTextKey

==>backingIndex=search

==>compositeIndex=false


I used this to created the indices...

mgmt.buildIndex(s"${k}TextKey", classOf[Vertex]).addKey(u, Mapping.TEXT.asParameter()).buildMixedIndex("search")
mgmt.buildIndex(s"${k}StringKey", classOf[Vertex]).addKey(u, Mapping.STRING.asParameter()).buildMixedIndex("search")




Character case behaviour different with or without indices

ni...@...
 

This is odd behaviour in janusgraph.

If we have a user with a property, say Robert, we can't find him with a search for "Rob" but we can with a search for "rob".
 
gremlin> mgmt = graph.openManagement()
==>org.janusgraph.graphdb.database.management.ManagementSystem@793cef95
i
= mgmt.getGraphIndex('userStringKey')
==>userStringKey
gremlin
> i.getProperties()
==>unique=false
==>indexedElement=interface org.janusgraph.core.JanusGraphVertex
==>class=class org.janusgraph.graphdb.database.management.JanusGraphIndexWrapper
==>fieldKeys=[Lorg.janusgraph.core.PropertyKey;@72110818
==>mixedIndex=true
==>baseIndex=userStringKey
==>backingIndex=search
==>compositeIndex=false


gremlin
> g.V().has('user', textRegex( '.*Rob.*')).properties()
gremlin
> g.V().has('user', textRegex( '.*rob.*')).properties()
==>vp[user->Robert]
==>vp[v_key->0G4WNqlqyv-J1PTmYnF2]
==>vp[type->user]
gremlin
> g.V().has('user', textRegex( 'robert')).properties()
==>vp[user->Robert]
==>vp[v_key->0G4WNqlqyv-J1PTmYnF2]
==>vp[type->user]
gremlin
> g.V().has('user', textRegex( 'Robert')).properties()
gremlin
> g.V().has('user', textRegex( '.obert')).properties()
==>vp[user->Robert]
==>vp[v_key->0G4WNqlqyv-J1PTmYnF2]
==>vp[type->user]



If there is no index, the behaviour is different
 
graph = JanusGraphFactory.open('/tmp/tmp.prop')
g
= graph.traversal()
v1
= graph.addVertex('name', '1')
v2
= graph.addVertex('name', '2')
edges
= ['xxx', 'xxx.yyy', 'Xxx.yyy', '111.222', 'abcdef'].collect {
    v1
.addEdge('relates', v2, 'p', it)
}
gremlin
> g.E().has('p', textRegex( '.*X.*')).properties()
==>p[p->Xxx.yyy]
gremlin
> g.E().has('p', textRegex( '.*Xxx.*')).properties()
==>p[p->Xxx.yyy]
gremlin
> g.E().has('p', textRegex( '.*xxx.*')).properties()
==>p[p->xxx]
==>p[p->xxx.yyy]

Is this a bug, or is there some subtlety I missed?


Re: Janus Graph performing OLAP with Spark/Yarn

Jason Plurad <plu...@...>
 

I posted an answer for SparkGraphComputer with YARN for TinkerPop 3.2.4 over on gremlin-users. The approach works similarly for JanusGraph 0.1.1.

I'll echo sjudeng's comments on matching the Spark version exactly. Spark is very picky about that.

# conf/hadoop/read-cassandra.properties

# TinkerPop Hadoop Graph for OLAP
gremlin
.graph=org.apache.tinkerpop.gremlin.hadoop.structure.HadoopGraph
# Set the default OLAP computer for graph.traversal().withComputer()
gremlin
.hadoop.defaultGraphComputer=org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputer

# I/O Formats
gremlin
.hadoop.graphInputFormat=org.janusgraph.hadoop.formats.cassandra.CassandraInputFormat
gremlin
.hadoop.graphOutputFormat=org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoOutputFormat
gremlin
.hadoop.inputLocation=none
gremlin
.hadoop.outputLocation=output

# JanusGraph-Cassandra InputFormat configuration
janusgraphmr
.ioformat.conf.storage.backend=cassandra
janusgraphmr
.ioformat.conf.storage.hostname=192.168.70.101
janusgraphmr
.ioformat.conf.storage.port=9160
janusgraphmr
.ioformat.conf.storage.cassandra.keyspace=janusgraph

# Apache Cassandra InputFormat configuration
cassandra
.input.partitioner.class=org.apache.cassandra.dht.Murmur3Partitioner

# Gremlin Console acts as the Spark Driver (YARN client)
spark
.master=yarn-client
spark
.executor.memory=512m

# When true, jars from HADOOP_GREMLIN_LIBS become added jars available via http to executors
# In Spark 1.6.1, jars are added but don't appear to be available...
gremlin
.hadoop.jarsInDistributedCache=false

# Install JanusGraph on all worker nodes, then add jars with local fs path
spark
.executor.extraClassPath=/home/vagrant/_/opt/janusgraph-0.1.1-hadoop2/lib/*

-- Jason


On Wednesday, May 31, 2017 at 10:09:28 PM UTC-4, sjudeng wrote:
I think there are many success stories/snippets out there on this but no consolidated how-to that I'm aware of. Marc I'm pretty sure I've seen plenty of examples from you on this across various lists over the years. I can contribute a couple examples as well if we can get some documentation started on this under JanusGraph. I've had success getting traversals and vertex programs working using Titan SparkGraphComputer with HBase using both TinkerPop-3.0.1/Spark-1.2 (Yarn/Cloudera) and TinkerPop-3.2.3/Spark-1.6 (Yarn/Cloudera and Mesos). But haven't tested this out with JanusGraph yet. Personally I'd recommend you consider running Spark on Mesos instead of Yarn if possible. The configuration is easier in my opinion and you can have apps running against different versions of Spark, making hardware and software updates much easier and less disruptive.

A few notes in case helpful: First is probably obvious but I always match the server Spark version exactly to the Spark version in TinkerPop from the relevant JanusGraph/Titan distribution. Also I've found the spark.executor.extraClassPath property to be crucial to getting things working both with Yarn and Mesos. Jars included there will be at the start of the classpath, which is important when the cluster may have conflicting versions of core/transitive dependencies. I'll usually create a single jar with all dependencies (excluding Spark), put it somewhere accessible on all cluster nodes and then define spark.executor.extraClassPath pointing to same.


Indexing issue...

Rafael Fernandes <luizr...@...>
 

Reindexing has been tough for me too, so I had to write few wrapper classes and tons of debugging to make sure I didn't miss anything, but what I found out was that, some of my transactions were still opened, remember, titan/Janus open several threads and they might have opened transactions that you don't know about...

I'd suggest the following, if you can:
1) stop all your app servers
2) use gremlin console or write a simple java program
3) execute steps 29.1.5.1, http://docs.janusgraph.org/latest/index-admin.html
3.1) set this storage.parallel-backend-ops=false
3.2) set this ids.num-partitions=1
3.3) depending how large your graph is, this shouldn't take long...
4) once your indexes are done, bring up your servers.

That should do the trick, it did for me...
Enjoy,
Rafa


Indexing issue...

Gene Fojtik <genef...@...>
 

Hello,

Currently having issues creating indexes on our graphdb with the following configs..
- Gremlin Server (Janus Server)
- Cassandra backend
- ES index backend

From an empty graph, imported a graphml which implicitly defined the schema.

Added indexes per steps & documentation.. however during the await step, we continue to timeout.   There are no open transactions or connections - verified.
mgmt.awaitGraphIndexStatus(graph, 'indexname').call()

We continue to receive the following..
Update action [REINDEX] cannot be invoked for index with status [INSTALLED]

4 eyed the steps to ensure we followed properly - seems like we are missing something..  Any assistance is appreciated.


Re: Buiding JanusGraph Cluster.

HadoopMarc <m.c.d...@...>
 

Hi Naveen,

You are right, the various JanusGraph deployment options are a bit hidden in the documentation. You can find them at:

http://docs.janusgraph.org/latest/cassandra.html

A bit older, but more literary explanation can be found in:

https://dzone.com/articles/titan-server-single-server

Cheers,     Marc

Op zaterdag 3 juni 2017 01:21:07 UTC+2 schreef Naveen Kumar Eppa:

Hey Guys,

I am new to this Graph database world, i am actually trying to build a 3 node JanusGraph  cluster in Docker.

I am not sure how Janus instances communicate with each other. 


Buiding JanusGraph Cluster.

Naveen Kumar Eppa <nave...@...>
 

Hey Guys,

I am new to this Graph database world, i am actually trying to build a 3 node JanusGraph  cluster in Docker.

I am not sure how Janus instances communicate with each other. 


Re: Is JanusGraph suitable for Ad Tech ?

Ted Wilmes <twi...@...>
 

This may or may not help with hotspotting, depends on your access patterns. Also, If you are expecting to make queries that have to touch all of the incident edges on a high degree vertex, as opposed to some small selective subset (by filtering on an edge property), you probably will need to run these using TinkerPop's OLAP options[1] that can be used with JanusGraph. High degree vertices (super nodes) are still a pain point for many graph engines, some just extend the upper limit of what is considered a reasonable number of edges further than others.


On Friday, June 2, 2017 at 9:17:58 AM UTC-5, Jakub Liska wrote:
Wow, I was looking for this whole day, thanks Ted !! It will need some serious play time but I believe that it must be used by people, especially 
those having these hotspots.

This is exactly what makes JanusGraph useful even for absolutely graph unrelated use cases.


Re: Reindex job

Jerry He <jerr...@...>
 

Looked at the code.   The timeout is 180 seconds.
private static final int TIMEOUT_MS = 180000;

It is not customizable.  There is a configuration property 'storage.read-time', which does not seem to apply or be used here.

It is trying to fetch the next batch of rows from the backend. I am still curious why it could timeout with 180 seconds.

Thanks.

Jerry

On Wed, May 31, 2017 at 10:26 PM, Joe Obernberger <joseph.o...@...> wrote:

Hi Jerry - HBase appears to be healthy.  The graph is about 65 million nodes and 74 million edges.

-Joe


On 6/1/2017 1:05 AM, Jerry He wrote:
How big is your graph?  Is your HBase healthy? 
I wonder what the default timeout duration is. 
It is like a JanusGraph timeout, not a HBase timeout.

Thanks.

Jerry

On Wed, May 31, 2017 at 2:36 PM, Joe Obernberger <joseph.o...@...> wrote:
Hi All - I have a graph that I'd like to add an index to.  I've tried it through gremlin with a smaller graph and the procedure works fine.  With a larger graph, however, I get a timeout error:

gremlin> mgmt.updateIndex(mgmt.getGraphIndex("fullNameIndex"),SchemaAction.REINDEX).get()
17:18:34 ERROR org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor - Exception occured during job execution: {}
org.janusgraph.diskstorage.TemporaryBackendException: Timed out waiting for next row data - storage error likely
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor.run(StandardScannerExecutor.java:150)
        at java.lang.Thread.run(Thread.java:745)
17:18:34 ERROR org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor - Processing thread interrupted while waiting on queue or processing data
java.lang.InterruptedException
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2014)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2088)
        at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor$Processor.run(StandardScannerExecutor.java:272)
17:18:34 ERROR org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor - Could not load data from storage: {}
java.lang.RuntimeException: java.io.InterruptedIOException
        at org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:97)
        at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
        at org.janusgraph.diskstorage.hbase.HBaseKeyColumnValueStore$RowIterator.hasNext(HBaseKeyColumnValueStore.java:295)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor$DataPuller.run(StandardScannerExecutor.java:325)
Caused by: java.io.InterruptedIOException
        at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:188)
        at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:60)
        at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:210)
        at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:327)
        at org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:410)
        at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:371)
        at org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:94)
        ... 5 more
17:18:34 ERROR org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor - Could not load data from storage: {}
java.lang.RuntimeException: java.io.InterruptedIOException
        at org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:97)
        at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
        at org.janusgraph.diskstorage.hbase.HBaseKeyColumnValueStore$RowIterator.hasNext(HBaseKeyColumnValueStore.java:295)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor$DataPuller.run(StandardScannerExecutor.java:325)
Caused by: java.io.InterruptedIOException
        at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:214)
        at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:60)
        at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:210)
        at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:327)
        at org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:410)
        at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:371)
        at org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:94)
        ... 5 more
17:18:34 ERROR org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor - Could not load data from storage: {}
java.lang.RuntimeException: java.io.InterruptedIOException
        at org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:97)
        at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
        at org.janusgraph.diskstorage.hbase.HBaseKeyColumnValueStore$RowIterator.hasNext(HBaseKeyColumnValueStore.java:295)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor$DataPuller.run(StandardScannerExecutor.java:325)
Caused by: java.io.InterruptedIOException
        at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:214)
        at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:60)
        at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:210)
        at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:327)
        at org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:410)
        at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:371)
        at org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:94)
        ... 5 more
org.janusgraph.diskstorage.TemporaryBackendException: Timed out waiting for next row data - storage error likely
Type ':help' or ':h' for help.
Display stack trace? [yN]n


Any ideas?  I've also tried this through Java code, but I get a different error:

17/05/31 17:14:37 INFO job.IndexRepairJob: Found index fullNameIndex
17/05/31 17:14:37 ERROR scan.StandardScannerExecutor: Exception trying to setup the job:
java.lang.IllegalStateException: Operation cannot be executed because the enclosing transaction is closed
        at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.verifyOpen(StandardJanusGraphTx.java:299)
        at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.getRelationType(StandardJanusGraphTx.java:891)
        at org.janusgraph.graphdb.query.QueryUtil.getType(QueryUtil.java:61)
        at org.janusgraph.graphdb.query.vertex.BasicVertexCentricQueryBuilder.constructQueryWithoutProfile(BasicVertexCentricQueryBuilder.java:456)
        at org.janusgraph.graphdb.query.vertex.BasicVertexCentricQueryBuilder.constructQuery(BasicVertexCentricQueryBuilder.java:399)
        at org.janusgraph.graphdb.olap.QueryContainer$QueryBuilder.relations(QueryContainer.java:129)
        at org.janusgraph.graphdb.olap.QueryContainer$QueryBuilder.edges(QueryContainer.java:165)
        at org.janusgraph.graphdb.olap.job.IndexRepairJob.getQueries(IndexRepairJob.java:216)
        at org.janusgraph.graphdb.olap.VertexJobConverter.getQueries(VertexJobConverter.java:157)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor.run(StandardScannerExecutor.java:103)
        at java.lang.Thread.run(Thread.java:745)
17/05/31 17:14:37 ERROR job.IndexRepairJob: Transaction commit threw runtime exception:
java.lang.IllegalArgumentException: The transaction has already been closed
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
        at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.commit(StandardJanusGraphTx.java:1356)
        at org.janusgraph.graphdb.database.management.ManagementSystem.commit(ManagementSystem.java:235)
        at org.janusgraph.graphdb.olap.job.IndexUpdateJob.workerIterationEnd(IndexUpdateJob.java:133)
        at org.janusgraph.graphdb.olap.job.IndexRepairJob.workerIterationEnd(IndexRepairJob.java:76)
        at org.janusgraph.graphdb.olap.VertexJobConverter.workerIterationEnd(VertexJobConverter.java:118)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor.run(StandardScannerExecutor.java:125)
        at java.lang.Thread.run(Thread.java:745)
Exception in thread "Thread-14" java.lang.IllegalArgumentException: The transaction has already been closed
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
        at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.commit(StandardJanusGraphTx.java:1356)
        at org.janusgraph.graphdb.database.management.ManagementSystem.commit(ManagementSystem.java:235)
        at org.janusgraph.graphdb.olap.job.IndexUpdateJob.workerIterationEnd(IndexUpdateJob.java:133)
        at org.janusgraph.graphdb.olap.job.IndexRepairJob.workerIterationEnd(IndexRepairJob.java:76)
        at org.janusgraph.graphdb.olap.VertexJobConverter.workerIterationEnd(VertexJobConverter.java:118)
        at org.janusgraph.diskstorage.keycolumnvalue.scan.StandardScannerExecutor.run(StandardScannerExecutor.java:125)
        at java.lang.Thread.run(Thread.java:745)
17/05/31 17:14:37 INFO client.ConnectionManager$HConnectionImplementation: Closing master protocol: MasterService
17/05/31 17:14:37 INFO client.ConnectionManager$HConnectionImplementation: Closing zookeeper sessionid=0x35b92203553bdf6
17/05/31 17:14:37 INFO zookeeper.ZooKeeper: Session: 0x35b92203553bdf6 closed
17/05/31 17:14:37 INFO zookeeper.ClientCnxn: EventThread shut down

Thanks for any ideas!

-Joe

--
You received this message because you are subscribed to the Google Groups "JanusGraph users list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Virus-free. www.avg.com


6381 - 6400 of 6661