Client is not registered with the server-side
Symptom
No data appears in the subscribed client list.
Cause
The client is not registered with the server-side.
Solution
Confirm that the client has started.
Confirm that the application name and executor name in the console configuration match the names in the client code. Also, check that the endpoint configuration is correct.
If the client has already started, check the
common-default.logandcommon-error.logerror logs in thelogs/schedulerfolder.If no errors are found in the error logs, view the health check log to confirm that the health check passed.
Deploying multiple clients on a single instance causes connection failures
Do not deploy multiple AntScheduler clients on a single instance, such as an ECS instance, virtual machine, or pod. This causes connection preemption issues.
Incorrect AntVIP address configuration
Symptom
The following error is reported: `[AntVIPRouter] Get scheduler servers failed`.
Cause
The AntVIP address is configured incorrectly.
Solution
Check the AntVIP address in the client application's configuration file. For more information, see Import SOFA middleware.
Task scheduling client is offline
Symptom
The task scheduling console shows that the client is offline.
Cause
A persistent TCP connection could not be established between the client and the server-side.
Solution
If the console shows that the client is online, a persistent TCP connection was successfully established between the client and the server-side. Two factors are required to establish a TCP connection:
The client obtains the server-side IP address and port.
The network between the client and the server-side is accessible.
The client first retrieves server-side information, such as the IP address and port, from AntVIP and then establishes a connection. After the connection is successful, the console shows the client as online. However, if configuration information such as `antvip` or `instanceId` is incorrect, an `endpoint might be wrong` error occurs.
Failed to delete a task
Symptom
The following error is reported: `can not delete running job`.
Cause
The task is running and cannot be deleted.
Solution
Wait for the task to finish running or manually pause the task, and then delete it.
Version editing conflict
Symptom
The following error is reported: `${draft_version} is editing, can not create new version with ${base_version}`.
Cause
Only one version can be edited at a time from the same base version `${base_version}`. For example, if `${draft_version}` is being edited, you cannot create another new version from `${base_version}`.
Solution
Publish a new version using one of the following methods:
Publish the version being edited, `${draft_version}`, and then create a new version based on `${base_version}`.
When creating a new version, select another published version as the base version.
Retry issue with scheduling records
Symptom
In the task scheduling records, some records have a Retry button, while others do not.
Cause
If a task has multiple execution records, only the latest record has a retry option. This is because older records are no longer relevant.
Business application does not receive message-based tasks
Troubleshooting steps
Check if the message event code in the task configuration of the task scheduling console matches the one in the message console configuration.
If the message event codes match, check if the topic for the message task in the message console configuration is set to TP_F_SC. If not, change it to TP_F_SC.
If the topic is configured correctly, check the task scheduling server-side log to see if the message was sent successfully.
If the task scheduler sent the message successfully, see the SOFAMQ FAQ for further troubleshooting.
AntScheduler health check returns 503
Symptom
A health check on the `curl 127.0.0.1:8080/health` endpoint fails and returns "DOWN".
#curl 127.0.0.1:8080/health {"status":"DOWN"}A health check on another endpoint, `curl 127.0.0.1:8080/health/readiness`, passes and returns "UP".
Cause
Incorrect endpoint.
Solution
Upgrade the MS version to 2.34 or later. After the upgrade, the `/health` endpoint can forward requests internally to the `/actuator/readiness` endpoint.
The `curl 127.0.0.1:8080/health/readiness` endpoint can also be used for health checks.