[fedora-java] Packaging tomcat shell scripts
rrati at redhat.com
Thu Jan 16 15:43:08 UTC 2014
On 01/09/2014 10:34 AM, Robert Rati wrote:
> On 11/07/2013 05:22 AM, Severin Gehwolf wrote:
>>>> Since I've come along systemd's tomcat at foo service file recently
>>>> while packaging thermostat in rawhide, what is preventing you from
>>>> this for hadoop httpfs? It worked quite nicely for us, since we didn't
>>>> have to ship our own systemd service file. We now simply use $
>>>> start tomcat at thermostat for firing up tomcat with a CATALINA_BASE
>>>> in /var/lib/tomcats/thermostat.
This will work for hadoop's httpfs service and obviously works for
thermostat, but I don't think is the direction that should be taken by
most webapps. The problem with the tomcat at foo service as used by
thermostat is that it fires up an instance of tomcat and deploys the
webapp. That works great if:
A) there is only 1 webapp that needs to run at any time with tomcat at foo
B) all webapps use the same port
C) the system tomcat isn't running
If A or C is false, tomcat at foo won't work. The problem is that all
tomcat instances use the same server.xml file, so all try to use the
same Connector setup. Whichever tomcat instance starts first will work
fine. Try to launch a second and you get port collisions and tomcat
goes down taking the previously running instance with it.
If B is false you end up running webapps that listen on ports other than
what upstream uses, potentially causing confusion and/or breakage with
whatever might interact with the webapp.
> I've finally gotten the time to look at this solution and it looks like
> there could be issues with multiple webapps deploying the way thermostat
> does. I'm not a tomcat expert so I'm probably missing something, but
> here are the concerns I have:
> 1) With all webapps using the same configuration files, wouldn't the
> logs become a mess? From my testing of thermostat, it places all logs
> in /usr/share/tomcat/logs with no unique extensions save a single
> exception (thermostat-web-storage). If multiple webapps launch this
> way, won't the logs be incomprehensible?
This is what happens. All catalina logging ends up in the
/var/log/tomcat directory (symlinked to from /usr/share/tomcat/logs).
The mess isn't as bad as it could be because only 1 instance can be
running at at time. Try to launch two and these log files become a
record of the tomcat errors.
> 2) What ports end up being used by these webapps if they all use the
> same configuration? It seems like there'd be a logjam on 8005. What
> about webapps that want to use different ports? Is that needed/allowed?
> Can this be done with the config file in sysconfig?
There is a logjam on port 8080 (not 8005). Every tomcat instance uses
the same configuration files with the same Connector configuration
resulting in all instances listening on the same port.
Looking at other webapps besides thermostat, many seem to install
themselves into /usr/share/tomcat/webapps and are run by starting tomcat
itself. I would think this is the preferred way to deploy webapps.
Unfortunately installing into /usr/share/tomcat/webapps won't work for
httpfs because httpfs uses system.getProperty to retrieve system
properties to configure the service. I don't see a way to get around
this requirement and as far as I've found there is no way to provide
these values on a per-webapp basis. The only way I've found to provide
the values is as options passed to tomcat on invocation.
The tomcat at foo allows you to define options that will be passed to
tomcat on invocation, but there seems to be no co-ordination/plan for
how tomcat at foo1 will run along side tomcat at foo2 or the system tomcat.
Should the goal be to allow these various methods of deploying a webapp
to run on the same machine?
More information about the java-devel