Comments in-line.
On 5/28/2013 10:21 AM, vicky007aggar...@yahoo.co.in wrote:
Thanks David & Chris for responding back.
Actually i am doing a proof of concept,in which in want to use the
same CATALINA_BASE across in lieu of creating 10 different tomcat
instances.
I am doing this by using variables in server.xml for port
numbers,work directories etc. & then i am passing the respective
values to the tomcat startup script as arguments.
The idea is to get away from the need of creating tomcat instances &
to have one common config file which will be used for running
multiple instances using single catalina_base .with this i can
reduce lot of support work & it will be easier to maintain as well.
I'm not sure how this solves a lot of support and maintenance problems.
So your script would look like the following?
ascript.sh -Dshutdown.port=xxxx -Dhttp.port=yyyy -Dajp.port=zzzz
(etc., etc., etc.)
How do you track all of these 10 instances? Do you write 10 scripts with
this information embedded in them, one script that reads a parameters
file, or . . . .?
So for an operator to manage this (start, stop, etc.), the person would
have to know 10 different invocations of your script (shorter if you
store parameters in files).
Then, if your operators like GUI interfaces, how do these scripts get
folded into a services GUI like those provided by RedHat, et al?
My current method of managing all of this is something like the following:
a. Single CATALINA_HOME
b. CATALINA_BASE per usage (where usage is nebulously defined)
c. init.d service script per CATALINA_BASE
d. One or more Host elements per CATALINA_BASE
I have one Ant script that does the work of creating b) and c) from a).
I have another Ant script that does the work of managing d).
The Ant scripts read property files that serve as documentation for
CATALINA_BASE and the Host elements. There are lots of nice comments in
the property files.
xmltask and the external tidy program work great for most of the XML
mangling tasks.
It takes me longer to edit the property files than it does to create the
actual new instance. Maybe I'll store the information in a Derby
database, query it, and compute the next appropriate value . . .
Operators can start, stop, restart, check status on each service from
the command line, or add the service to the GUI and do it that way.
Upgrading is still a little bit of a challenge, but I'm working on a
script that will help discover and merge changes from new versions of
CATALINA_HOME/conf/*. Right now, I do the check manually, and modify the
Ant script if there has been a change in the Connector or Host elements
(none so far).
If things get a little crazier, I'll look at something like Puppet or Chef.
So related to this My Queries are :-
1) do you guys find this approach as reliable in which i will be
passing the port numbers,work directory location & catalina base to
tomcat startup script as argument on runtime???
I always worry about typing errors. I worry about typing errors a lot
more when I'm root. Relying on adding arguments at run time seems to be
dangerous. Also, how would you script this as a service?
2) Are there any concerns/pitfalls which i should take care ?
See above. I'm thinking that there are three issues.
a. typos, typos, typos
b. automated scripts for services / operators
c. documentation, documentation, documentation
3) i am not able to
create separate temp directory for the instances ,is it possible to
change the temp location which is used by tomcat instances or it can
be shared across multiple instances ?
Why not?
a. Create an unprivileged user for running Tomcats
b. Do not allow remote access - su to that user only (accounting is
nice)
c. Create everything for Tomcat in that directory (except service
scripts)
d. Use service scripts or jsvc to run Tomcat instances
You have one place to back up, one place to upgrade, tools for creating
new instances and new Host nodes in the instances, and the operator
interface ends looking like any other service.
You could use the system's temp directory by overriding java.io.tmpdir.
Note that serialized sessions are placed here, so if there is sensitive
information that may not be a good idea.
Work directories is another matter. This is where Tomcat translates JSP
to Java, and then compiles the resulting servlet. I can imagine some not
too pleasant complications if:
a. Multiple Tomcats share the same work directory
b. Multiple Tomcats use the same Host element (localhost for example)
c. Multiple Tomcats run different versions of the same web application
You're likely to get collisions in:
work_dir/Catalina/localhost/app_name/org/apache/jsp
I'd have to look at the code, but I think Tomcat just checks timestamps
and not size or content. I'm not sure how Tomcat would differentiate
between two versions of the same JSP from different Tomcats sharing the
same work directory.
Please suggest i really need your guidance.
Thanks, Vicky
This seems to be a lot of effort in order to solve a problem that's not
really all that huge (especially for 10 Tomcat instances).
. . . . just my two cents
/mde/
On May 28, 2013, at 9:56 PM, David kerber <dcker...@verizon.net>
wrote:
On 5/28/2013 12:22 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Vicky,
On 5/28/13 2:30 AM, vicky007aggar...@yahoo.co.in wrote:
Is there is a way by which we can create work& temp
directories on run time so that we can avoid creating multiple
tomcat instances having there individual work& temp
directories.
Can you ask that question in a different way, or explain in a
little more detail? It's unclear to me what you are trying to
achieve.
It looks to me like she wants to have single work and temp
directories, to be used by all tomcat instances. Though I'm not
sure what the "on run time" is referring to.
- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
