Restarting a Tomcat application is sometimes the fastest and safest way to recover from a bad deploy, clear a stuck state, or load updated configuration. In a managed hosting environment, the decision should be based on symptoms, recent changes, and how your Java application is running inside the control panel. A restart is not a routine action for every issue, but it is often the right first recovery step when the app stops responding, shows stale code, or needs a clean reload of its JVM-side resources.
In an ITA Java hosting setup with My App Server, you can run your own Apache Tomcat instance or private JVM inside a shared hosting account, manage it through Plesk, and choose from available Java and Tomcat versions. That makes restarts practical for small and medium Java web apps, JSP sites, and servlet applications that need controlled operational changes without moving to a full enterprise platform.
When a Tomcat restart is usually the right move
A restart is appropriate when you need to return the application to a known good state. Common cases include:
- The application is not responding, but the server and service control look healthy.
- A WAR file, JSP, servlet, or configuration change was deployed and the app is still serving old content.
- The application has memory growth, thread stalls, or resource exhaustion symptoms that a reload may clear.
- A new Java version, Tomcat version, or environment setting requires a fresh service start.
- Session state, cached files, or temporary artifacts appear to be stuck after a deployment or update.
- You changed context configuration, environment variables, or connector settings and need Tomcat to re-read them.
In hosted environments, a restart is also useful after recovering from a transient issue such as a failed dependency, a short-lived lock, or an incomplete application startup. If the problem is limited to the application process itself, restarting Tomcat is often faster than changing platform settings or making unnecessary code changes.
When you should not restart immediately
Restarting too early can make diagnosis harder, especially if the issue is caused by the application code, a bad database connection string, a broken build, or missing files. Before restarting, check whether the problem is actually persistent.
- If the error appears only once and then clears, monitor first.
- If logs show a clear application exception, fix the underlying cause before restarting.
- If the failure happens during startup every time, a restart will usually repeat the same error.
- If other services are affected, the issue may be outside Tomcat and require broader investigation.
For example, if a JSP error is caused by a missing library or a broken classpath, restarting will not solve it. If Tomcat cannot start because the Java version is incompatible with the app, you need to correct the version selection or deployment package first.
Typical signs that a restart is needed
You should consider restarting a Tomcat application when you see one or more of the following signs:
1. The app is stuck or partially down
The site loads some pages but fails on others, requests hang, or the application begins timing out. This often suggests that the JVM or the web application has entered an unhealthy state.
2. New code is not showing
After deploying a WAR or updating JSP files, the old version still appears. Tomcat may be caching classes or holding onto compiled JSP artifacts until the app is restarted.
3. Configuration changes are not applied
Changes to server-side properties, environment settings, or application resources sometimes require a clean restart to take effect.
4. Memory or thread usage is abnormal
If the application becomes sluggish, consumes increasing memory, or stops handling requests reliably, a restart can restore service while you investigate the root cause.
5. A failed startup left the service in an inconsistent state
After a bad deploy or interrupted stop/start cycle, the app may need a full restart to clear temporary files and reload all resources cleanly.
Restarting the application vs restarting the whole service
In a Tomcat hosting environment, you may have two different operational actions: restarting the application and restarting the underlying service. They are not always the same.
- Application restart: reloads the deployed web app while keeping the broader service context available.
- Tomcat service restart: stops and starts the Tomcat process or private JVM itself.
Use an application restart when the issue appears limited to the deployed app, such as stale classes, session-related issues, or a partial reload problem. Use a service restart when the JVM, Tomcat process, or connector layer seems unhealthy, or when a clean service-level reset is needed after a broader configuration change.
With My App Server in Plesk, this distinction helps you avoid unnecessary downtime. If your app can be recovered with a simpler restart action, that is usually the safer choice.
What to check before restarting in Plesk or My App Server
Before you restart, collect a few basic signals so you can confirm whether the action worked and avoid repeating the same fault.
- Check the application error log for recent exceptions.
- Review the Tomcat log for startup or shutdown messages.
- Confirm whether the Java version and Tomcat version match your app requirements.
- Check recent deployments, uploads, or configuration edits.
- Look for failed database connections, missing files, or permission issues.
If your hosting panel provides service control, verify that the service is actually running before you trigger a restart. Sometimes the application is down because the service has already stopped or failed to launch.
Safe restart steps for a hosted Tomcat application
The exact steps depend on how your hosting account is configured, but the operational sequence is usually similar.
Step 1: Confirm the issue
Open the site or application endpoint and note the symptoms. Record whether the issue is a timeout, 500 error, blank page, stale content, or deployment failure.
Step 2: Review logs
Check the app logs and Tomcat logs for any recent exceptions, stack traces, or startup messages. This helps you separate a temporary glitch from a deeper problem.
Step 3: Verify recent changes
Ask whether a new WAR file, library, JSP update, or configuration change was deployed shortly before the issue started. If yes, make sure the deployment is complete and correct.
Step 4: Use the control panel restart option
In Plesk, or through the My App Server service controls, restart the application or service in the least disruptive way available. If the platform offers a specific Tomcat restart action, use that first.
Step 5: Wait for full startup
Do not refresh the site immediately. Let Tomcat complete startup and initialize the web application. A restart that is checked too early can look like a failure when it is still booting.
Step 6: Test the app
Confirm that the main page loads, key actions work, and updated content is visible. If possible, test a simple JSP or endpoint first, then verify any business-critical function.
Step 7: Re-check logs after restart
Make sure the restart actually resolved the issue and did not trigger a new exception, out-of-memory condition, or deployment warning.
When to restart after deploying a WAR or JSP update
Deployment changes are one of the most common reasons to restart a Tomcat application. You may need a restart after:
- Uploading a new WAR file
- Replacing compiled classes or libraries
- Updating JSP pages that are cached or precompiled
- Changing web.xml, context settings, or init parameters
- Modifying environment-dependent resources
A restart helps Tomcat unload old classes and rebuild the application state cleanly. This is especially useful in hosted Java environments where your app runs in its own private JVM and you want deterministic deployment behavior.
If the application still shows old content after a restart, check for browser caching, reverse proxy caching, or duplicated deployment paths. The issue may not be Tomcat itself.
Restarting after a failed startup or bad deploy
If a deployment fails and Tomcat does not come up cleanly, a restart can sometimes clear temporary state and let the application start properly on the next attempt. However, do not assume the restart is the cure. First confirm that the uploaded package is complete and valid.
Look for these problems before trying again:
- Missing JAR files or classes
- Wrong Java version for the application
- Broken context path or filename
- Database credentials that no longer work
- Permission issues on uploaded files
When the deployment package is fixed, a clean restart is often the fastest way to bring the app back online.
Operational tips to reduce restart downtime
Even in a small hosting environment, you can reduce disruption by following a few practical habits:
- Restart during low-traffic periods when possible.
- Check logs before and after every restart.
- Keep a copy of the last known good WAR or deployment package.
- Document which Java and Tomcat version the app requires.
- Test the app locally or in staging before making changes live.
- Use a simple rollback plan if the new deployment does not start correctly.
These steps are especially useful for hosted Tomcat applications where downtime should be short and predictable. A restart should be part of a controlled operational change, not a guessing exercise.
Common mistakes to avoid
Many restart problems are caused by avoidable operational errors rather than Tomcat itself.
- Restarting repeatedly without checking the logs.
- Assuming a restart will fix code, dependency, or database errors.
- Forgetting that browser or proxy caches may still show old content.
- Restarting the wrong service when multiple Java apps are available.
- Skipping validation after the service comes back online.
If the application keeps failing after multiple restarts, stop and investigate the root cause. Repeated restarts can create more downtime without improving the result.
How My App Server helps with restart and recovery tasks
In the My App Server model, the application runs under your control inside a hosted account, with access to practical service actions through Plesk. This is useful when you need straightforward Tomcat hosting for JSP, servlet, or WAR-based applications without the overhead of managing a full enterprise stack.
Typical advantages for restart and recovery tasks include:
- Control over your own Apache Tomcat instance
- Choice of Java version for the application
- Simple service control through the hosting panel
- Ability to deploy, restart, and test without deep system administration
- Support for private JVM-style operation within a shared hosting account
This makes it easier to perform safe operational changes when your app needs a restart, while keeping the process manageable for smaller Java projects.
FAQ
Should I restart Tomcat after every deployment?
Not always, but it is often a good idea when the deployment includes new classes, libraries, JSP changes, or configuration updates that need a clean reload. If your platform or deployment method supports a safer application reload, use the least disruptive option first.
Will restarting Tomcat fix a 500 error?
Sometimes, but not always. A 500 error can be caused by stale state, a broken deploy, or a temporary JVM issue. It can also be caused by application bugs, missing files, database problems, or configuration errors that a restart will not solve.
How do I know whether to restart the app or the whole service?
If the issue seems limited to the deployed web application, try an application restart first. If the Tomcat process, JVM, or service itself appears unhealthy, restart the full service through the control panel.
Is a restart safe for session-based applications?
A restart may clear active sessions unless your application stores them externally or is designed to preserve state. Plan downtime carefully if users are logged in, and warn them when needed.
What should I check if the app still does not work after restart?
Review the logs again, verify the deployment package, confirm the Java and Tomcat versions, and check for dependency or database issues. If the restart completed successfully but the app still fails, the problem is usually in the application itself.
Can I restart a Tomcat app from Plesk?
In a managed hosting setup with My App Server, service control is available through the panel. The exact buttons and workflow depend on your account setup, but the aim is to make Tomcat restart and recovery tasks straightforward.
Conclusion
Restarting a Tomcat application in the UK market is usually the right choice when the app is stuck, stale, or needs a clean reload after deployment or configuration changes. In a hosted Java environment, especially with My App Server and Plesk, a restart is a practical operational tool: it can restore service quickly, apply changes cleanly, and reduce downtime when used at the right moment.
The key is to restart for the right reason. Check logs first, confirm recent changes, choose the least disruptive restart option available, and validate the result after the service comes back. That approach gives you faster recovery without hiding the real problem behind repeated restarts.