User Experiences and Discussions in WLOADCTL

Q: How do I activate the product in a completely offline internal network?

A: The product uses an offline activation mechanism and the server does not need to connect to the public internet. After installation, the product automatically generates an Installation ID. On a computer that has internet access, use this Installation ID to visit the official website and obtain the authorization code. Then, bring the authorization code back to the isolated server and register it to complete the activation.

---

Q: Does WLOADCTL support Docker deployment?

A: Yes, it is technically supported, but it is strongly not recommended by the official guidance. WLOADCTL uses a database-free architecture; all scheduling data is stored as files in the storage. Deploying it via Docker fails to leverage its lightweight advantages and instead introduces additional complexities and difficulties regarding upgrades and maintenance.

---

Q: Can different process containers depend on each other? If I strictly need to use the "lean" dependency attribute, how should I handle cross-process dependencies?

A: The "lean" dependency attribute is mainly used for forced dependencies within the same process. For dependencies between different processes (projects), here are the standard methods:

• 1. Dependencies within the same process:

  • The most common method is using the Serial/Parallel graph – the sequential relationship between jobs represents the dependency.
  • If the sequential relationship cannot be easily drawn or expressed, you can use the lean forced dependency attribute.

• 2. Dependencies between different processes under the same scheduling service:

  • Flag File Method: Add a "create flag file" job after Job1 in Process A; add a "check flag file" job before Job2 in Process B.
  • Event Trigger Method: Use the built-in "Send Event" and "Receive Event" components to replace the creation and checking of flag files.

• 3. Dependencies between processes on different scheduling services (e.g., Server A1 and Server B1):

  • Shared Storage Method: If both servers can access the same path (e.g., shared storage or a multi-user agent via shared path), use the same flag-file logic mentioned above. If they do not share storage, ensure they can access the same path.
  • Command-Line Event: In the process on Server A1, send the event using the command-line program ctlsendevent. In the process on Server B1, use the built-in "Receive Event" component to wait for that event.

---

Q: During Linux installation, it prompts that the server disk space exceeds the threshold, and the service will not start. What should I do?

A: This is a built-in default security detection mechanism for the scheduling node. If the disk space usage exceeds 97%, the scheduling service will refuse to start. Please check the server's disk space usage, clean up unnecessary files, and ensure the usage rate drops below 97% before restarting the scheduling service.

---

Q: The KJB job log reports an error: class drive org.git.mm.mysql.Driver could not be found, but it runs perfectly fine in Kettle. Why is this happening?

A: This is a typical issue of a missing or incompatible MySQL JDBC driver. Although Kettle can run locally, the scheduling service might fail to locate the driver class due to different environment paths or class-loading rules.
Solution: Place the correct MySQL driver JAR (e.g., mysql-connector-java-5.1.49.jar) into the data-integration\lib directory.

• Note: For MySQL 5.x, use the 5.1.x driver. For MySQL 8+, use mysql-connector-j-8.x and update the connection class name to com.mysql.cj.jdbc.Driver.
• Important: Restart the scheduling service (or the Kettle plugin) after placing the JAR file for it to take effect.

---

Q: How do I specify which Linux user executes a Shell script?

A: In WLOADCTL, the user that executes a Shell script depends on the Node Installation User. WLOADCTL executes jobs through the agent program on the nodes. The agent program runs as whichever OS user installed and started it; therefore, all jobs assigned to that node will default to executing under that user. To run a script under a specific user, ensure that the agent on that node is installed and started by the target user, or configure the user settings in the Node Management section.

If you encounter other issues, please contact:
General inquiries: [e-mail]
Technical assistance: [e-mail]