Managing ThingWorx Extensions in the ThingWorx HA
In a ThingWorx HA configuration, ThingWorx extensions are stored in the database and cached in the local file system. This is to ensure that a new ThingWorx leader can resume operations using the latest extensions stored in the database.
During its startup, the ThingWorx leader 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 these steps, it will attempt to back out of the import. The zip is persisted last so that if the extension fails to deploy, the extension will not be deployed to the database for other standby nodes to pick up and cause corruption.
ThingWorx Leader Extension Review Process
When a ThingWorx leader starts, the following steps are performed for each extension:
1. The extension is undeployed.
2. Its checksum value is read from the checksum file named ThingworxStorage/extensions/<extension name>/<extension name>.chk.
3. The extension's checksum value is read from the persistence layer.
4. These two checksum values are compared.
a. If the checksum values are the same
a. ThingWorx regards database and local extensions to match
b. No changes are made.
b. If the checksum values do not match
a. The copy of the extension's zip is read from the persistence layer.
b. It is extracted into a temporary directory, such as ThingworxStorage/extensions/temp/<extension name><random>
c. The old version of the extension is deleted from ThingworxStorage/extensions/<extension name>
d. The copy of the extracted zip is copied into the old extension directory ThingworxStorage/extensions/<extension name>
e. A new checksum file is created in the extension directory ThingworxStorage/extensions/<extension name>/<extension name>.chk
f. The extension is deployed.
If the system fails during any of the above steps, it will attempt to clean up what it can. If the old copy of the extension cannot be replaced with the copy from the persistence layer, the old copy is loaded.
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.