Reset Runtime
In the previous microlearning, we covered how to restart runtimes without affecting their underlying data or configurations. This time, we will delve into the process of resetting a runtime, which is a more thorough approach that essentially starts from scratch. We will explore when and why a reset might be necessary, and how it differs from a restart. Resetting a runtime can be particularly useful in cases of memory issues or during major updates. Let’s get started!
Should you have any questions, please contact academy@emagiz.com.
1. Prerequisites
- Intermediate knowledge of the eMagiz platform
- Intermediate knowledge of runtime management
2. Key concepts
This microlearning centers around resetting a runtime.
- With resetting, we mean: Ensure that we begin with a clean slate and forget about what happened before
3. Reset runtime
In the previous microlearning, we learned about restarting runtimes. In that microlearning, we learned that restarting the runtime does not affect flows, data, psychical hardware, or otherwise. It is simply jump-starting the runtime or machine once more. In this microlearning, however, we will focus on the action to reset a runtime. A reset on the other hand is the more aggressive approach and does have a significant effect. In other words, the main difference is that with a reset you begin with a clean slate compared to the simple restart.
Having said that there are some cases where it can become beneficial to reset a runtime. For instance when running into memory issues or when doing large bulk build number upgrades.
In short, the reset action can be described by the following:
- A reset is the more aggressive approach compared to a restart.
- The reset does the following on runtime level:
- Stops the runtime service (if running)
- Removes data (except Artemis folder + revision info)
- Removes local repository folder
- Starts the runtime service (if stopped at step 1)
- With a reset, you start with a clean slate
- Flow version could be different based on changes in the release
- Custom H2 database is emptied
To execute this action please navigate to Deploy -> Architecture (if you are not there already). After you have done so you can access the context menu of a particular runtime (via a right mouse click), while in "Start Editing" mode, and select the option called "Reset runtime".
By pressing this button your executes all steps mentioned above.
To verify that everything went correctly and your runtime is running correctly you can access the details pop-up on Architecture level. In here you can access the "Status" tab to check the status of your runtime.
Subsequently you can double check this by looking at the logs under Manage -> Log Entries.
Note that when you have a custom H2 database on runtime level (i.e. for storing metadata) the H2 database will be deleted as well when you remove the runtime. To safeguard against this you could store your H2 database on EFS. Please take a look at the help text for the URL field on the JDBC H2 connection pool component for more information.
4. Key takeaways
- A reset is a more aggresive action compared to a restart. While a restart simply reboots the runtime without affecting its data or configuration, a reset clears out data and settings, effectively starting with a clean slate.
- The reset does the following on the cloud level:
- Stops the runtime service (if it’s running).
- Removes most runtime data (excluding the Artemis folder and revision information).
- Removes the local repository folder.
- Restarts the runtime service (if it was stopped at Step 1).
- After a reset, you will:
- Begin with a fresh state, which might include different flow versions depending on changes in the release.
- Have an emptied custom H2 database.
- Consider resetting a runtime if you encounter memory issues or need to perform significant updates.
5. Suggested Additional Readings
If you are interested in this topic and want more information, please read the help text provided by eMagiz and check out these links: