Post-migration and post-upgrade rudiments · WorkFusion Documentation

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 worker-execution.yml file for a pipeline (hyper model). The parameter was introduced starting 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 worker-execution.yml file for the pipeline:

Replace heap with the memory parameter.
Delete the heap parameter from the file.
Redeploy the pipeline.

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 (hyper model). 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 ZooKeeper parameter /config/worker-management-service/bep.worker.override.automl-model-service.execution.memory, and then 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 ZooKeeper parameter config/worker-management-service/bep.worker.override.automl-model-service.execution.memory to /config/worker-management-service/bep.worker.override.automl-model-service.execution.heap.

View also: