|
Still a VPS or dedicated server subject, with administrator access. There is no Java and no Tomcat on our shared hosting servers. The install is in installing Tomcat on a server of your own; this is what comes next.
|
A freshly installed Tomcat works, and is not ready. Four things are missing, and they are always the same four: the port it answers on, the memory it gets, who may reach the management pages, and the web server in front of it handling the address and the certificate.
1. Where it listens, and who can reach it
Tomcat’s main configuration is a file in the conf folder. That is where you set the port it answers on, and also the address it answers on, which is the part almost everybody skips.
| 1 |
Bind it to the machine itself. If you are putting a web server in front, and you should, Tomcat only needs to answer from inside. Then, even if the firewall slips one day, nobody outside talks to it directly.
|
|
| 2 |
Disable the shutdown port. Tomcat ships with a separate port whose job is to tell it to stop. On an exposed server that is one extra door with no purpose, because whoever administers the machine stops it through the system service anyway.
|
|
| 3 |
Confirm with your own eyes. After restarting, list the listening ports and see which address Tomcat shows up on. If it shows up on all of them, the change did not take.
|
|
On which ports have to be open, and why an integration hangs without producing an error, the subject is covered in which ports are open.
2. Memory, which causes the most trouble
Java reserves memory for itself and manages it its own way. Give it too little and the application dies out of memory halfway through a request. Give it too much and the operating system runs out of headroom and eventually kills the process, which gives you a service that vanishes leaving no error in the application at all.
| 1 |
Do not edit Tomcat’s startup scripts. There is a dedicated file in the bin folder that exists precisely to hold your options and that survives upgrades.
|
|
| 2 |
Leave the system some room. Server memory is not all for Java: the system, the database and the web server need theirs. Handing Java nearly all of the machine’s memory is the classic mistake.
|
|
| 3 |
Set the minimum equal to the maximum on a server dedicated to this one application. It stops the process spending its life growing and shrinking, which is wasted work.
|
|
| 4 |
Measure before you pick a number. Run the application in anger for a few days and see what it actually uses. A value copied from a tutorial knows nothing about your application.
|
|
If the service starts disappearing in the small hours with no explanation, memory is the first suspect. The typical symptoms on a server of your own are in common VPS and Cloud errors.
3. The management pages, which are how these servers fall
Tomcat ships with browser based management applications. They are useful, and they are by far the most scanned target on an installation. Deal with them on day one.
| What to do |
Why |
| Delete what you do not use |
The sample applications serve no purpose in production and have been an entry point before now. If you do not use them, do not have them. |
| Real names and real passwords |
Management accounts are defined in their own file in the conf folder. No obvious names, no short passwords, and one account per person. |
| Restrict by address |
Each management application has a context file where you can restrict who reaches it. Let in your office only, or the machine itself only. |
| Never over the internet unencrypted |
If you must administer from outside, do it through an SSH tunnel rather than publishing the management page. |
4. The web server in front
This is the piece missing from nearly every broken installation that reaches us. You put an Apache or an Nginx on the normal web port, with the certificate, and it passes requests to Tomcat inside the machine. You gain everything at once:
| 1 |
The address looks normal, with no odd port number stuck on the end.
|
|
| 2 |
The certificate is handled in one place, with tools you already know, instead of being configured inside Java.
|
|
| 3 |
You can run more than one site on the machine, each on its own name.
|
|
| 4 |
Static files come from the web server, which does that better and more cheaply than Tomcat.
|
|
| 5 |
Tell Tomcat it is behind an intermediary. Without that, the application sees every visitor as coming from the machine itself, and your logs, your access rules and your counts all start lying to you.
|
|
|
Deploying an application is copying a file. Drop the application package into the applications folder and Tomcat installs it itself. To replace it, copy the new one over. Done that way, an update is one command and one line in the logs, not an evening.
|
|
Start and stop through the system service, always. Running the startup scripts by hand creates a process the system does not know about: it does not come back after a reboot, it does not show in the status, and one day you have two Tomcats fighting over the same port. One command to start, one to stop, one to check, and nothing else.
|
|
Got a Java application to put online and not sure what machine it needs? Describe the application to us.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $9.99/mo See plans |
Português
English
