How to pick a servlet hosting company: Servlet installation and logistical issues
There are a couple of "logistical" considerations. An advantage of some servlet
hosting plans is that they make explicit how exactly to install servlets, and
give you the tools to check that you are within their resource limits:
- check that they give clear instructions on how to install servlets: which
location to transfer files to, and what the URL of the installed servlet will be;
- a company with support information such as an on-line forum or
documents detailing how to set up database access from your servlet would be a bonus;
- check that they have a clear policy on what they count as "fair use" in terms
of CPU and memory usage that your servlets are allowed to consume, and that
they actually provide a tool for you to check the resources you are using.
The last point is particularly important. Beware of hosting sharks who:
(a) impose very low limits, such as a maximum of 1% CPU usage and a pitiful memory
allocation; (b) reserve the right to disable your server without notice
if you go over the limit; (c) don't actually provide a tool for you to check if you
are near or over the limit. If your servlet is for any serious use, do not
pick a company that cannot give you an unequivocal answer to these issues. A decent
provider should not randomly disable your account or servlets without prior notice, and should
provide you with the necessary tools to monitor your resource usage. Ideally, they
should also provide you with a means of purchasing more resources as necessary.
Remember that moving hosting company later will waste time, will
probably leave your ste down for a period, and
may incur extra development costs as
there will inevitably be parts of your servlet written to the specific configuration
of the account you're using. For example:
- means of accessing databases is likely to be different on
a new system;
- the configuration of the new company may have their servlet
container configured differently (e.g. one may resolve host names but another
not)– so certain features you rely on in one environment may not be
available in another.
In other words, choosing a restrictive plan to save a few dollars a month
may prove costly in the long run. I know because I've made this mistake in the past.
Where to go next:
If you enjoy this Java programming article, please share with friends and colleagues. Follow the author on Twitter for the latest news and rants.
Editorial page content written by Neil Coffey. Copyright © Javamex UK 2021. All rights reserved.