Mixed Index is directly going to ENABLED state when created causing awaitGraphIndexStatus to timeout

[mrckzgl]

• Version: 0.6.1
• Storage Backend: berkleyje
• Mixed Index Backend: lucene
• Expected Behavior: Mixed index should go into REGISTERED state or awaitGraphIndexStatus should also listen to ENABLED state
• Current Behavior: Mixed index goes into ENABLED state causing awaitGraphIndexStatus to timeout
• Steps to Reproduce:

Using JRuby, this is our config:

Java::OrgJanusgraphGraphdbDatabase::StandardJanusGraph.__persistent__ = true
DB = org.janusgraph.core.JanusGraphFactory.build
       .set("storage.backend","berkeleyje")
       .set("storage.directory", DB_FOLDER)
       .set("allow_upgrade",false)
       .set("jvm_cache","50")
       .set("timestamp_provider","NANO")
       .set("index.search.backend","lucene")
       .set("index.search.directory","#{DB_FOLDER}/index")
       .set("query.batch-property-prefetch","true")
       .set("query.fast-property","true")
       .set("query.force-index","true")
       .open()

Build a mixed index like so:

manager = DB.open_management
manager.make_property_key("search_value").dataType(Java::JavaLang::String.java_class).cardinality(Cardinality::LIST).make()
index = manager.build_index index_name, Java::OrgApacheTinkerpopGremlinStructure::Vertex.java_class
index.add_key(search_key, Java::OrgJanusgraphCoreSchema::Mapping::TEXT.as_parameter)
manager.commit
watcher = key_manager.class.await_graph_index_status(DB, index_name)
watcher.call

According to https://docs.janusgraph.org/schema/index-management/index-lifecycle/ the index should after the manager.commit call be in REGISTERED state and needs to be enabled manually (or using reindex). As such, the watcher per default will wait only for the REGISTERED state.

In our case however, the watcher.call will consume exactly 60 seconds, without any CPU activity, which is its default timeout.
Also, the index is usable without manually enabling it. I assume as such that the commit call directly puts the index in ENABLED state.

This can be confirmed when also listening for ENABLED state like so:

manager = DB.open_management
manager.make_property_key("search_value").dataType(Java::JavaLang::String.java_class).cardinality(Cardinality::LIST).make()
index = manager.build_index index_name, Java::OrgApacheTinkerpopGremlinStructure::Vertex.java_class
index.add_key(search_key, Java::OrgJanusgraphCoreSchema::Mapping::TEXT.as_parameter)
manager.commit
watcher = key_manager.class.await_graph_index_status(DB, index_name)
watcher.status(org.janusgraph.core.schema::SchemaStatus::REGISTERED, org.janusgraph.core.schema::SchemaStatus::ENABLED)
watcher.call

The watcher.call now will immediately return without the timeout.

[porunov]

Hi @mrckzgl

That is optimization which was implemented in #1192 and #1949 (see issue #1190 and #1947).
This behavior is described in the doc here.

Graph indexes built against newly defined property keys, i.e. property keys that are defined in the same management transaction as the index, are immediately available. The same applies to graph indexes that are constrained to a label that is created in the same management transaction as the index.

---

I don't have strong opinion here, but maybe doc improvement could be done because it's a second time I see the issue being raised regarding this behavior.
cc @FlorianHockmann @rngcntr

[rngcntr]

I like @mrckzgl's suggestion from the other comment to make awaitGraphIndexStatus listen to ENABLED in addition to REGISTERED in case no status is explicitly defined. That would be a one line change here that makes sense to me.

[mrckzgl]

Thanks for pointing the docs. As a user getting to know JanusGraph currently, from documentation point of view I can only provide you feedback that this documentation did not work. The information you cited should IMHO be presented also in https://docs.janusgraph.org/master/schema/index-management/index-lifecycle/ otherwise it will go unnoticed (as it did in my case). If one follows the suggestion to wait for the index as described by ManagementSystem.awaitGraphIndexStatus(graph, "myIndex").call(); one will just be surprised that it will take so long. It would be very good if at that point it is mentioned that in some cases index will go into ENABLED stated directly and one would need to also listen to the ENABLED state or, well, why not let awaitGraphIndexStatus listen to ENABLED by default? Actually this is what I would expect from such call after reading both docs: index-lifecycle and index-performance/#graph-index or in other words, in the docs it is nowhere mentioned that awaitGraphIndexStatus will timeout if the index is already in a higher state than REGISTERED.

[mrckzgl]

EDIT: also the term available actually is ambiguous. It could mean both, state = REGISTERED and state = ENABLED