Skip to main content

Post-migration and post-upgrade rudiments

After migrations and upgrades, you may face issues caused by rudiments, such as those described below.

Case 1: model migration from v10.1.2+ to v10.1-​

Symptoms​

The event logs contain the error that Worker could not be started! Check Artifact|Launch configuration. because of Invalid maximum heap size: -XmxMError: Could not create the Java Virtual Machine.

Cause​

Commonly, the reason is in the heap parameter in the model's worker-execution.yml file. The parameter was introduced from v10.1.2+. Therefore, older WorkFusion versions (for example, v10.0.x or v10.1.x) cannot handle it, and the Worker for the model processing fails to start.

Solution​

Edit the model's worker-execution.yml file:

  1. Replace heap with the memory parameter.

  2. Delete the heap parameter from the file.

  3. Redeploy the model.

Case 2: model migration from v9.x to v10.x​

Symptoms​

All your input documents go to a Manual Task. In the event log, you may find an error message that the Worker could not be started or some artifacts are missing, for example, Worker group com.workfusion.custom.sdk:ie:1.0:execution could not start!

Cause​

9.x and 10.x models are not fully compatible. In 10.x versions, models include new files, and some internal classes of feature extractors, annotators, and post-processor are replaced, removed, or changed. Thus, your 9.x model is not compatible with a v10.x environment.

Solution​

If you have a training set, retrain the model in the new environment with a new pipeline. In the process, new 2.0 and 3.0 Search Engines are engaged. To keep your old model, refer to the migration guide.

Case 3: changes in ZooKeeper for v10.1- and upgrading to v10.1.4+​

Symptoms​

Let's imagine you have a v10.0 instance, you modify the /config/worker-management-service/bep.worker.override.automl-model-service.execution.memory ZooKeeper parameter, and upgrade to v10.1.4.

The issue is very similar to Case 1. Due to these changes and the upgrade, your platform doesn't know how to manipulate the heap parameter. A v10.1.4+ platform has the heap parameter by default, and thus it conflicts even with default models.

Cause​

The ZooKeeper behavior is still investigated, and a permanent solution to remove the rudiment is to be found.

Solution​

The main idea suggested to remove it permamently is to change the config/worker-management-service/bep.worker.override.automl-model-service.execution.memory ZooKeeper parameter to /config/worker-management-service/bep.worker.override.automl-model-service.execution.heap.

View also: