JanusGraph index stuck in "INSTALLED" state after running REGISTER_INDEX command

[rg2609]

I'm trying to create a composite index on the title property in JanusGraph using the Gremlin console.

Here's what I've done so far:

1. Created the title property key.
2. Built a unique composite index on this key named byTitleUnique.
3. Waited for the index to show in the INSTALLED state using

mgmt.getGraphIndex('byTitleUnique').getIndexStatus(mgmt.getPropertyKey('title'))

4. Attempted to update the index status to REGISTERED using the following commands:

mgmt = graph.openManagement()
mgmt.updateIndex(mgmt.getGraphIndex('byTitleUnique'), SchemaAction.REGISTER_INDEX).get()
mgmt.commit()

After running the command and waiting a long time (even over an hour), the index status still remains in the INSTALLED state.

As per my understanding, after this step, I should be able to Reindex and then Enable the index. But since the index isn’t moving past the INSTALLED state, I'm stuck.

---

Questions:

• Why isn't the index transitioning from INSTALLED to REGISTERED after
  running the command?

• Is there anything else I need to do to make this transition happen?

• Could this be related to the backend (I'm using Cassandra and
  Elasticsearch)?

Any help or insights would be appreciated.

[ntisseyre]

I have run into a similar issue with my C* storage as well.

In my case, it turned out that JanusGraph could not obtain a lock on the index to start the reindexing.
I didn't have time to dig into the root cause, but this workaround helped me to bypass it:

Add in your storage config just for re-indexing purposes:
storage.cql.use-external-locking=true.
https://docs.janusgraph.org/v0.4/basics/configuration-reference/

Once re-indexing is done, please turn it off.

[rg2609]

@ntisseyre Thank you for your response; it has really helped us create the index. We have successfully created the index. Now, when we try to query the database, we are getting the error 500: Could not call index.

we are trying following query:

data = self.g.V().has_label(_label)  # Filter nodes by label
        if node_title:
            data = data.has("title", _title)
        data = (
            data.has(property_type)  # Ensure the property is not null (exists)
            .order()
            .by(property_type)
            .values(property_type)  # Get the property values
            .dedup()  # Return distinct values
            .to_list()
        )

log trace as follow:

File "/home/abc/gremlin_queries.py", line 1671, in get_all_node_property_values
    data.has(property_type)  # Ensure the property is not null (exists)
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/process/traversal.py", line 65, in to_list
    return list(iter(self))
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/process/traversal.py", line 48, in __next__
    self.traversal_strategies.apply_strategies(self)
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/process/traversal.py", line 694, in apply_strategies
    traversal_strategy.apply(traversal)
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/driver/remote_connection.py", line 78, in apply
    remote_traversal = self.remote_connection.submit(traversal.bytecode)
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/driver/driver_remote_connection.py", line 105, in submit
    results = result_set.all().result()
  File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 439, in result
    return self.__get_result()
  File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/driver/resultset.py", line 90, in cb
    f.result()
  File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 432, in result
    return self.__get_result()
  File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/driver/connection.py", line 90, in _receive
    status_code = self._protocol.data_received(data, self._results)
  File "/usr/local/lib/python3.8/site-packages/gremlin_python/driver/protocol.py", line 138, in data_received
    raise GremlinServerError(message['status'])
gremlin_python.driver.protocol.GremlinServerError: 500: Could not call index
 

[ntisseyre]

Could not call index is a generic error JanusGraph throws when the underlying storage system is experiencing a problem. You need to dig into your logs to find the root cause of the issue, potentially with Cassandra.

[rg2609]

Thank you for your response. We made an effort to create indexes for two property keys by setting up both Composite and Mixed index types for each. However, we encountered a "500: Could not call index" error, which prompted us to reassess our approach. As a constructive solution, we decided to delete all existing indexes and focus on creating a single Composite index for one of the property keys, which is now working fine. However, we weren’t able to get it to function when we also had the Mixed index in place. My question is: Can we only have one type of index on a single property key, or am I missing something?

[porunov]

@rg2609 most likely you faced a ghost JanusGraph instance by improper shutdown of the previous JanusGraph instances.
Check the answer here on how to resolve this issue:
#3195 (comment)

If you are new to schema initialisation, you may benefit from the JSON schema initializer: https://docs.janusgraph.org/schema/schema-init-strategies/

Here is a useful configuration option from docs (useful during testing, but be careful to not use it in Prod):

Users who struggle to initialize schema due to created zombie JanusGraph instances in the cluster may leverage configuration option schema.init.json.force-close-other-instances. This option will automatically close all JanusGraph instance in the cluster (including activate instances).