If a JSP deployment stops responding after a restart, the problem is usually not the restart itself, but one of the following: Tomcat did not come back cleanly, the application did not deploy after the JVM started, the wrong Java version is selected, or an earlier process is still holding the port. In a private JVM hosting setup, the safest recovery path is to verify the service state first, review the deployment logs next, and then restart only the affected application service or Tomcat instance instead of making repeated full restarts.
In a Plesk-based Java hosting environment with My App Server, you can normally recover from a failed restart without rebuilding the whole account. The goal is to confirm whether the issue is at the service level, the runtime level, or the application level. The steps below are written for JSP hosting, Tomcat hosting, servlet hosting, and private JVM hosting where you manage your own Java runtime from the control panel.
What a failed restart usually means
A failed restart does not always mean the server is down. In most cases, it means one of these states occurred:
- The Tomcat service stopped, but did not start again.
- The JVM started, but the web application failed during deploy.
- The application came up, but the expected JSP pages return errors or time out.
- A previous Java process is still running and blocking the new start.
- The selected Java version is incompatible with the application.
- The application exceeded a resource limit and could not complete startup.
For hosted JSP applications, a restart should be treated as a controlled recovery operation. Repeated clicking on the restart button can make diagnosis harder, especially if the application needs a few seconds to release ports, rebuild caches, or finish an incomplete shutdown.
First checks after the restart fails
Before changing anything, check the basic status in your hosting control panel. In most cases, this saves time and prevents unnecessary redeployment.
1. Check whether the service is running
Open the service control area for your Java app server in Plesk and look for the current state. If the service is marked as stopped, failed, or starting for too long, note that status before attempting another action.
If the control panel shows that the service is running, but your JSP site still does not load, the problem is more likely inside the application or web context, not the JVM itself.
2. Review the service control messages
Look for any error message shown by the service control interface. Common messages include:
- Port already in use
- Java runtime not found
- Startup timeout
- Application deploy failed
- Permission denied
Even a short error line can point directly to the cause. If your hosting provider gives access to a service log or startup log, review that next.
3. Confirm the Java version
A failed restart often happens after a runtime change. If the app was installed on one Java version and then started with another, the application may fail immediately or deploy with runtime errors. Confirm that the selected Java version matches the needs of your WAR, JSP, or servlet application.
4. Check whether the application was fully deployed
Sometimes Tomcat restarts successfully, but the app is not fully available because deploy unpacking or initialization did not finish. If the control panel shows a separate status for the application, verify that the application itself is active and not just the runtime.
Safe recovery steps for a failed restart
Use the following sequence. It is designed for private JVM hosting in a managed environment where Tomcat is controlled through a hosting panel rather than direct server administration.
Step 1: Stop the service once, then wait briefly
If the service is stuck in a half-started state, issue one clean stop command from the control panel. After that, wait a short time before starting it again. This gives the JVM time to release resources, close the port, and finish shutdown tasks.
Do not immediately click restart multiple times. A second start request while the first stop is still being processed can create duplicate process conflicts.
Step 2: Verify that no old process remains
If your control panel exposes process information, confirm that the Tomcat or Java process is no longer active. An old process can keep the HTTP port busy and prevent a new instance from starting.
Typical signs of a lingering process include:
- The service appears stopped, but the application still responds partially.
- The next start fails instantly with a port error.
- The startup log shows bind failures on the same port.
If your environment does not allow direct process management, contact support and mention that the previous JVM instance may not have terminated cleanly.
Step 3: Start the service and watch the startup result
Start the service once, then wait for the status to settle. A healthy Tomcat startup should complete without repeated retries. In a My App Server environment, the control panel should reflect that the service is running, and the application URL should respond normally after a short delay.
If the service starts but the app does not load, continue with application-level checks instead of forcing another full restart.
Step 4: Check the application logs
For JSP hosting and Tomcat hosting, the most useful information is often inside the application or Catalina logs. Look for:
- Class loading errors
- Missing JAR files
- Failed database connections
- Servlet initialization exceptions
- Compilation problems for JSP pages
- OutOfMemoryError or thread exhaustion
If the restart failed because the application could not initialize, the logs usually show the exact class, line, or dependency that caused it.
Step 5: Roll back recent changes if needed
If the restart failure began after a deployment, configuration edit, or Java version change, revert the most recent change first. This is often the fastest recovery method in a hosted environment.
Common rollback actions include:
- Restoring the previous WAR file
- Reverting changes to web.xml or context settings
- Switching back to the previous Java version
- Removing a newly added library that conflicts with the runtime
Step 6: Redeploy the application cleanly
If the service is up but the application is broken, remove the failed deployment and upload a clean copy of the WAR or application package. In many JSP hosting setups, stale unpacked files can prevent a clean redeploy. If the panel provides a redeploy or refresh action, use it once after confirming the runtime is healthy.
For manually managed custom app servers, ensure the deployment directory is consistent with the application version you intend to run.
Common causes and how to fix them
Port conflict after restart
This is one of the most common causes. Tomcat tries to bind to a port already in use by another process. The port may still be held by the old JVM, another application, or a leftover service instance.
Fix:
- Stop the service cleanly.
- Wait a few moments.
- Check for a lingering process.
- If needed, change the configured port only if your hosting setup allows it and you know the application URL impact.
Wrong Java runtime selected
Some JSP applications require a specific Java version. After a restart, the app may fail if the selected runtime changed or was updated.
Fix:
- Check the configured Java version in My App Server.
- Switch to the version recommended by the application.
- Restart the service once after the change.
Application startup exception
If the service comes up but the application fails, there is often a Java exception during initialization. This can happen when a database is unreachable, a config file is invalid, or a library is missing.
Fix:
- Review the log message from the first failed startup attempt.
- Compare the current deployment with the last known working version.
- Restore missing files or remove incorrect changes.
Out of memory or resource exhaustion
Private JVM hosting is convenient for small and medium Java applications, but startup can fail if the app needs more memory or if too many background tasks are launched during initialization.
Fix:
- Reduce application memory usage if possible.
- Disable heavy startup tasks.
- Check for excessive logs or large temporary files.
- Review the hosting limits for the account.
Broken JSP compilation or missing dependencies
If the restart appears successful but JSP pages return errors, the application may have compiled incorrectly or is missing one of its required libraries.
Fix:
- Clear temporary and compiled JSP cache if your setup supports it.
- Verify that all required JAR files are present.
- Redeploy the application package.
- Check for classpath conflicts between bundled libraries and server libraries.
How to recover without damaging the deployment
When a JSP deployment fails after restart, it is important to avoid actions that can make recovery harder.
Do not repeatedly force restart
Repeated restarts can create overlapping startup attempts, lock files, and confusing log entries. One controlled stop and one controlled start are usually enough to identify whether the problem is persistent.
Do not delete the whole application unless necessary
Deleting the app can remove useful evidence such as logs, unpacked files, and configuration state. If possible, preserve the failed deployment until you understand what changed.
Do not change multiple variables at once
If you change the Java version, redeploy the WAR, and edit runtime settings all at once, you will not know which change fixed or broke the app. Adjust one item at a time and test after each step.
Keep a backup of the last known good version
For JSP and servlet hosting, a known good WAR or deployment archive is often the fastest fallback. If the latest release fails after restart, you can restore the previous version and confirm whether the problem is in the application or the runtime.
Using My App Server in Plesk to recover faster
In the ITA Java hosting model, My App Server is designed to make private JVM control practical from the hosting panel. That matters during recovery because you can usually manage the runtime and application from one place instead of chasing settings across multiple tools.
Useful recovery capabilities often include:
- Starting and stopping the private JVM from Plesk
- Choosing from prepared Java/Tomcat versions
- Uploading and configuring a custom app server version
- Deploying WAR-based JSP applications
- Inspecting service state and restart results
If your deployment uses a custom Tomcat setup, make sure the startup parameters, port mapping, and Java selection all remain aligned after any recovery action. A restart can expose a pre-existing configuration issue that was not obvious while the service was running.
When to contact support
You should contact hosting support if any of the following is true:
- The service will not start after one clean stop and one clean start.
- The panel shows an error but the log does not explain it clearly.
- The application requires a runtime change you cannot apply yourself.
- You suspect a port conflict but cannot verify or clear it.
- The application starts, but JSP requests still fail with server-side errors.
When you contact support, include the exact restart time, the selected Java version, the application name, and any error text from the control panel or logs. This helps the support team determine whether the issue is with the runtime, the application package, or the hosting account configuration.
Recommended recovery checklist
- Check the service status in Plesk or the hosting panel.
- Read the last restart or startup message.
- Stop the service once and wait briefly.
- Make sure no old JVM process is still running.
- Start the service once and verify the result.
- Review application and Tomcat logs.
- Confirm the selected Java version.
- Rollback the last deployment change if needed.
- Redeploy the application cleanly if the runtime is healthy.
- Escalate to support if the service still fails to recover.
FAQ
Why does Tomcat start, but my JSP site still shows an error?
This usually means the JVM is running, but the application failed during deploy or initialization. Check the application logs, verify the WAR package, and confirm the Java version and dependencies.
Can I just restart the service again?
You can, but only once after verifying that the previous stop completed. If the first retry fails, continue with log review and configuration checks instead of repeating restarts.
What is the most common reason for a failed restart?
The most common reasons are a port conflict, a lingering process, an incompatible Java runtime, or an application startup exception.
Should I redeploy before checking logs?
No. Always check logs first if possible. Logs usually show whether the failure is caused by the application itself or the runtime environment.
Can a failed restart damage my JSP application?
A normal failed restart should not damage the application, but repeated forced attempts can create stale locks, partial deployment states, and confusing cache files. That is why a controlled recovery sequence is safer.
What if my custom app server version was manually uploaded?
Check that the uploaded runtime is complete and compatible with the selected Java version. A partial or mismatched custom app server can start incorrectly or fail during the first deploy after restart.
Conclusion
Recovering from a failed restart for a JSP deployment is usually straightforward when you approach it in order: verify service status, stop cleanly, confirm that no old process remains, review logs, and then restart or redeploy only what is necessary. In a Plesk-based private JVM environment with My App Server, this workflow is especially effective because it lets you manage Tomcat, Java version, and application deployment from one control point.
If the restart failure is caused by a recent change, rollback is often the fastest fix. If the cause is unclear, the logs will usually reveal whether the problem is in the runtime, the deployment package, or an application dependency. A careful, single-step recovery process is the best way to restore your JSP service quickly and safely.