Restarting a JSP application should be done when the runtime state is no longer reliable, not as a routine fix for every minor issue. In a managed hosting environment with Plesk and a private Tomcat or JVM instance, a restart can clear stuck sessions, reload updated classes and configuration, and recover from temporary resource pressure. It should not be used to mask an underlying code, memory, or deployment problem that will return after the next request spike.
For JSP hosting in the UK market, the practical question is usually not whether a restart is possible, but when it is the safest and most effective action. In a hosted Java environment such as My App Server, you can often restart only the Tomcat service or the private JVM behind the application, which is less disruptive than stopping the whole hosting account. The right timing depends on the symptom, the deployment method, and whether users are actively using the application.
When a JSP application should be restarted
A restart is appropriate when the application or its container is in a bad state and normal operations no longer behave as expected. Common examples include:
- changes to JSP files, Java classes, or configuration files do not appear after deployment;
- the application is returning 500 errors after a deployment or update;
- Tomcat or the JVM is consuming unusual memory and becomes slow or unresponsive;
- sessions, caches, or background threads appear stuck;
- the application stops responding even though Apache and the hosting account are still up;
- you changed environment variables, Java options, or startup settings that require a service reload;
- you see repeated errors in logs that point to a broken runtime state rather than a single request failure.
If the issue is isolated to one page or one user action, a restart is usually not the first choice. Check logs, recent changes, database connectivity, and application code before restarting. A restart may temporarily hide the symptom, but it will not fix broken JSP logic, missing libraries, or a misconfigured datasource.
Signs that the problem is in the container, not just the code
In JSP hosting, many issues come from the container layer rather than from the application source itself. Restarting is more justified when the symptoms suggest that Tomcat, the private JVM, or the deployed webapp has become inconsistent.
Typical container-level symptoms
- the application works after deployment, then degrades over time;
- memory usage keeps rising and does not fall after traffic drops;
- new JSP pages or servlet updates are not visible even after the file upload completed;
- class loading problems appear after replacing a JAR or WAR;
- the app hangs during startup and never becomes ready;
- threads remain active after requests finish;
- requests time out while Apache still serves other sites normally.
These are often signs that a service restart is the right next step, especially in a private JVM setup where you control the service directly in Plesk. In a shared hosting account with My App Server, restarting only the Java service is usually the safer operational change.
When you should not restart yet
Do not restart immediately if the problem is clearly linked to a recent code change and you have not reviewed logs. A restart may simply restore temporary service while leaving the root cause in place.
Hold off on restarting first if:
- you have not checked the application logs, Tomcat logs, or Apache error log;
- the issue is a predictable compile or syntax error in a JSP file;
- a required JAR or resource is missing from the deployment package;
- the database, cache, or external API is unavailable and the app depends on it;
- the application is already recovering on its own after a brief spike;
- you are still actively uploading files and the deployment is incomplete.
Restarting too early can make diagnostics harder, especially if logs rotate or temporary runtime state disappears. In managed hosting, it is usually better to gather evidence first unless the application is completely unavailable and every minute counts.
Best times to restart a JSP application in the UK
If the restart can wait, choose a low-traffic window. For a public-facing application, that often means outside business hours, during a scheduled maintenance window, or at a time when your own analytics show the lowest usage. UK businesses often prefer early morning or late evening for operational changes, but the best time depends on your audience and traffic pattern.
In a hosted environment, a JSP restart can briefly interrupt active sessions or in-flight requests. If the application is used for bookings, account actions, or live transactions, choose a quieter period and notify users if needed. Even a short restart can affect forms that are midway through submission.
Recommended timing checklist
- Review traffic levels in your analytics or access logs.
- Avoid restarting during peak ordering, support, or login periods.
- Confirm whether a deployment is already in progress.
- Warn internal users if the application is business critical.
- Make sure you can verify the service after restart.
Restart methods in a Plesk hosted Java environment
In a Plesk-based Java hosting setup, the exact restart method depends on how the application is installed. With My App Server, you typically manage the app server service from the control panel, which may include a Tomcat instance or a private JVM dedicated to your account.
1. Restart the app server service
This is the most common option when the whole Tomcat process needs a refresh. Use it when the application has become slow, stale, or unresponsive. A service restart clears the runtime state and reloads the application from disk.
2. Redeploy the application
If the issue follows a new upload, redeploying the WAR or refreshing the app structure may be enough. This is useful when class files, JSP pages, or configuration have changed and you want the container to rescan the deployment.
3. Restart only after a controlled update
When you know a code or configuration change requires a restart, schedule it after deployment rather than after users report a problem. This is usually the safest approach for maintenance releases, dependency updates, or changes to JVM options.
4. Restart after a failed startup
If Tomcat started with errors because a dependency was missing or a config value was invalid, fix the issue first and then restart. Restarting before correcting the cause only repeats the failure.
Practical restart procedure for JSP applications
A safe restart is more than clicking a button. A simple checklist helps avoid accidental downtime and makes recovery easier if something does not come back as expected.
Before restarting
- Check the latest application, Tomcat, and Apache logs.
- Confirm whether the issue is ongoing or already resolved.
- Identify any recent deployment, config, or dependency change.
- Back up modified JSP files, WAR files, and config files if needed.
- Note current service status and any visible error messages.
- Inform stakeholders if the restart may affect users.
During the restart
- Use the control panel or service control for the specific Java application.
- Prefer restarting the app server rather than the entire hosting account when possible.
- Wait for the service to stop cleanly before starting it again.
- Avoid repeated start/stop cycles, which can confuse diagnostics and prolong downtime.
After the restart
- Verify that the service is running normally.
- Open the application home page and a few key JSP paths.
- Check login, form submission, and any page that uses a servlet or backend call.
- Review logs for startup warnings or errors.
- Confirm that sessions, file uploads, and database connections behave correctly.
What to check if the application still fails after restart
If the JSP application does not recover after a restart, the cause is likely not a temporary runtime issue. At that point, move from recovery mode to troubleshooting.
Common causes of persistent failure
- bad JSP syntax or a compilation error;
- missing or incompatible JAR dependencies;
- wrong Java version for the application;
- invalid context path or web.xml configuration;
- database connection pool errors;
- out-of-memory conditions caused by code or traffic;
- permissions issues on the deployed files;
- corrupted WAR or incomplete upload.
If you use My App Server, check whether the selected Java version matches what the application expects. Some JSP or servlet projects run only on specific Java releases, and a mismatch can create startup failures that a restart will not solve. Also confirm whether the application is using a ready-made Tomcat version or a custom app server configuration, as startup behavior can differ slightly.
How My App Server affects restart decisions
In a shared hosting account with private Java support, the restart decision is often simpler because the Java runtime is separated from other hosted services. My App Server is designed to let you manage your own Tomcat or JVM instance from Plesk, which means you can restart the application server without touching unrelated websites or mail services.
This model is useful for JSP hosting, servlet hosting, and small to medium Java applications that need direct control over service state. It is also practical when you need to test a new Java version, replace a deployment, or recover from a stuck process without involving a full server reboot.
At the same time, it is important to keep expectations realistic. A restart is a service-management tool, not a substitute for enterprise clustering, high-availability orchestration, or complex failover architecture. For typical managed hosting use cases, it is a fast and effective recovery step when applied at the right moment.
Operational tips to reduce the need for restarts
You should not need to restart a JSP application frequently. If restarts are happening often, something in the deployment or application design likely needs attention.
- Keep JSP files, Java classes, and JAR dependencies versioned and documented.
- Separate configuration changes from code changes where possible.
- Monitor memory usage and request latency over time.
- Use a stable Java version supported by the application.
- Test updates in a staging environment before production deployment.
- Avoid unnecessary dynamic class reloading in production.
- Review slow database queries and resource leaks.
Good deployment hygiene reduces the number of emergency restarts and makes each restart more predictable. It also helps you identify whether the app server is being restarted for a valid operational reason or because the application has underlying stability issues.
Examples of restart scenarios
Example 1: New JSP changes do not appear
You upload updated JSP files, but users still see the old page. First confirm that the correct files were deployed. If the upload is complete and the server still serves stale content, restart the Tomcat service so the container reloads the webapp.
Example 2: Application became slow after several days
The app starts normally, but after a few days it becomes slow and memory usage rises. This suggests a possible memory leak, thread buildup, or cache issue. A restart may restore service temporarily, but you should still inspect logs and code to find the root cause.
Example 3: Startup fails after a configuration change
You modify a datasource or JVM option and the app no longer starts. In this case, correct the configuration first, then restart once. Repeated restart attempts will not help if the underlying setting is invalid.
FAQ
Should I restart a JSP application after every code change?
Not always. Small JSP updates may be picked up by the container depending on how the app is deployed and configured. However, changes to classes, libraries, context settings, or Java options often require a restart or redeploy. When in doubt, test the specific change in a controlled way.
Is restarting Tomcat the same as restarting the whole hosting account?
No. In a managed Java hosting setup, restarting the Tomcat or app server process is usually narrower and less disruptive. It refreshes the Java application without affecting unrelated services if the platform separates them.
Will a restart fix a 500 error?
Sometimes, if the error is caused by a transient container state. But if the 500 error comes from code, missing files, a bad database connection, or a configuration issue, the restart will only provide temporary relief or no benefit at all.
How do I know if the restart succeeded?
Check the app server status in Plesk, review the latest startup logs, and test a few key pages. The application should load normally, and the logs should not show new startup errors.
Can I restart only one JSP application?
Yes, in many hosting setups you can restart the app server or deployment related to one application rather than the entire account. With My App Server, this is a practical advantage for hosted JSP and Tomcat environments.
What if the application keeps needing restarts?
Frequent restarts usually indicate a stability problem such as memory leaks, thread issues, bad deployment handling, or an unsupported Java version. Investigate logs, traffic patterns, and recent changes rather than relying on restarts as a regular maintenance routine.
Conclusion
Restart a JSP application when the runtime state is clearly unhealthy, when a deployment needs the container to reload, or when Tomcat or the private JVM stops behaving normally. Do it at a low-traffic time when possible, and prefer restarting the app server service rather than the entire hosting environment. In a Plesk-based Java hosting setup with My App Server, that usually gives you the right balance of control and minimal disruption.
If a restart fixes the issue only briefly, treat it as a symptom and investigate the root cause in logs, configuration, Java version, dependencies, and application code. That approach will keep your JSP hosting more stable and reduce unplanned downtime.