Advanced Cassandra Actions

There are several actions for working with a Cassandra database which can be found in the NoSQL Storage plugin, under the Device Drivers / Plugins context. These actions allow for fine grain control over database security, as well as helping analyze corrupted contexts.

Create Cassandra User

The Create Cassandra User action creates a Cassandra user which requires a password.

To configure Iotellect to connect to Cassandra using a newly created user, open the NoSQL Configurations subgroup in the Storage group of the Global Configuration Options, and configure the following properties:

  • Use Authentication - Set to True.

  • Login - Use the Username of the new user.

  • Password - Use the Password of the new user.

Restart the server for the new configuration to take effect.

Optionally, use the action Drop Cassandra User to remove any other users.

Action Name:

createCassandraUser

Non-Interactive Mode:

Not Supported

Permissions:

Accessible at Administrator permission level

Drop Cassandra User

This action facilitates the removal of other users. The default Cassandra user has username cassandra, and can be dropped once a new user has been created and Iotellect has been configured to access the NoSQL database (as described above) with a different user.

Action Name:

dropCassandraUser

Non-Interactive Mode:

Not Supported

Permissions:

Accessible at Administrator permission level

Find Corrupted Contexts

In cases of disappearing or otherwise corrupted contexts, the Find Corrupted Contexts action makes it possible to locate affected contexts in the database for further analysis.

Action Name:

findCorruptedContexts

Non-Interactive Mode:

Not Supported

Permissions:

Accessible at Administrator permission level

Result Interpretation

When the Find Corrupted Contexts action is executed, the NoSQL driver returns a table in which each row represents a context that has been identified as potentially corrupted. A context is included in this result set when one or more critical integrity checks fail during the metadata scan. These checks validate that the context can be correctly reconstructed from the storage backend and that its structural metadata remains consistent.

Criteria for Detecting Corrupted Contexts

A context is considered corrupted if one or more of the following conditions occur:

Condition

Description

Missing or unreadable metadata entry

The Cassandra record storing the context’s definition cannot be read or is absent.

Broken or incomplete entity definitions

One or more variables, functions, events, or actions cannot be reconstructed from stored metadata.

Invalid or inconsistent table formats

A Data Table format stored for a variable or function contains structural inconsistencies (missing fields, invalid field definitions, incorrect version markers).

Checksum / version mismatch

Internal revision information does not match the expected version, suggesting partial writes or failed updates.

Orphaned child context references

A context references children that do not exist in storage, or whose metadata cannot be loaded.

Invalid parent reference

The context record indicates a parent that is missing or corrupted.

Deserialization errors

Any failure to deserialize stored metadata into a valid Context object.

Diagnosing Corrupted Contexts

Administrators can use the following techniques to diagnose the root cause:

  • Check server logs for metadata-related warnings and deserialization errors.

  • Inspect the NoSQL storage for missing or partially written records.

  • Verify recent replication operations, backup restores, or server crashes, as these may produce inconsistent metadata.

  • Attempt to load the context manually through the Context Tree browser; unreadable contexts typically fail to expand.

  • Compare with a backup to identify which metadata segments differ.

Depending on the severity and type of corruption, the following actions are typically used:

  • Rebuild the context from backup if metadata is unreadable.

  • Remove the corrupted context if it represents an unused or obsolete object.

  • Re-run replication for contexts that failed during copy operations.

  • Manually correct entity definitions (Data Table format or variable definitions) if only part of the context is affected.

  • Contact support if the corruption affects core system contexts or if mass corruption is detected.

The result table merely indicates that corruption was detected; the administrator must take follow-up steps according to the diagnostic information and system logs.

Was this page helpful?