Managing ThingWorx Extensions in ThingWorx HA
In a ThingWorx clustering configuration, ThingWorx extensions are stored in the database and cached in the local file system. This is to ensure that each ThingWorx instance is using the latest extensions stored in the database.
During its startup, ThingWorx checks the database for updates to extensions and applies them locally. If there is a discrepancy between the extensions in the database and extensions in the local ThingworxStorage/extensions directory, ThingWorx will regard the database version as the latest and the local ThingworxStorage/extensions version as out-of-date.
Extension Import Process
When extensions are imported, the system does the following:
1. Performs a checksum on the extension zip file and saves it to the ThingworxStorage/extensions/<extension name> directory as a <extension name>.chk file.
2. Unzips the zip to the ThingworxStorage/extensions/<extension name> directory.
3. Creates, deploys, and persists an ExtensionPackage entity (and any other entities) to the database.
4. Persists the zip file and the checksum to the database.
 |
If the system fails during the preceding steps, it will attempt to back out of the import. The zip file is persisted last. This is so that if the extension fails to deploy, it will not be deployed to the database and prevents other standby nodes from picking it up and causing corruption.
|
5. All servers will sync and install the extension.
The sync for an extension can take as long as the initial install of an extension. Each server in the cluster individually syncs and will be eventually consistent. During the sync time, imported entities will not be available on the other servers, only on the server where the initial import happened.
If you are importing a large number of extensions or extensions that will take a long time to sync, it is recommended to take the cluster down to a single instance, install the extensions, and then scale the cluster back up. This will be more performant and will prevent eventual consistency issues since the new extensions will be loaded by each server as they start.
|
|
While extension sync is running, other syncs will backup until it is completed.
|
Extension Removal Process
When extensions are deleted, the following occurs:
1. The extension is undeployed.
2. The zip is deleted from the database.
3. The ExtensionPackage entity is deleted from the database.
4. The ThingworxStorage/extensions/<extension name> directory is deleted, including the checksum.
5. All servers will sync and remove the extension.
The sync for an extension can take as long as the initial deletion of an extension. Each server in the cluster individually syncs and will be eventually consistent.
If you are deleting a large number of extensions or extensions that will take a long time to sync, it is recommended to take the cluster down to a single instance, delete the extensions, and then scale the cluster back up. This will be more performant and will prevent eventual consistency issues.
|
|
While extension sync is running, other syncs will backup until it is completed.
|