You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Robert Rowntree <ro...@realtimematrix.com> on 2009/06/15 05:26:56 UTC
deploy webapp to nfs shared drive
we are running a cluster of 3 nodes. we are on linux . we run tomcat 5.5.15
and do not use the server.conf clustering . we cluster tomcat with an
external load balancer.
we have tried using a context file like the example below in order to serve
webapps from the shared drive and have experienced the following differences
when compared to using locally attached storage for webapps:
Symptoms:
1. On a startup with a new war file positioned in the root directory for
the webapp the war file does not unpack. ./manager/list shows the app
running but it wont serve anything because war file never expanded.
2. in 'manager app' , using the GUI request 'reload' and the war file
does not unpack
3. in 'manager app' , using the GUI request 'undeploy' and the root
directory does not get deleted . the only thing that happens is the context
file from ./TomcatRoot/conf/Catalina/localhost is deleted.
when we put the $myapp.war file in the root directory , the war file does
not expand or unpack on a tomcat startup. ./Manager/list shows that 'myapp'
is 'running' but only the war file exists in the directoy. until we run an
explicit 'jar -xf $myapp.jar' no unpacking occurs. Only with the explicit
command do we get the result that we expect - unpacked war file is the
result.
Tomcat process runs under a user id that should have 'exec' permissions in
the directory where the war file is. The context for the webapp includes a
'background-processor-thread' .
Im trying to figure out whether it is more trouble to do multiple deploys of
the war file to each node in the cluster or whether we can have a reliable
procedure redeploying war files to a shared drive running on NFS..
--- context file for the webapp:
<Context path="/test" docBase="/mnt/nas1data/www/test" override="true"
backgroundProcessorDelay="10" />
--
Real Time Matrix Corp.
1900 Addison St., Suite 100
Berkeley, CA 94704
Office: 877-467-8601 EXT 710
Cell 415-335-5539
See our Gallery At
http://www.vortexme.com/vortex/?loc=gallery
The information contained in this message may be privileged, confidential,
and protected from disclosure. If the reader of this message is not the
intended recipient, or any employee or agent responsible for delivering this
message to the intended recipient, you are hereby notified that any
dissemination, distribution, or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify
us immediately by replying to the message and deleting it from your
computer. Thank you. Real Time Matrix.
Re: deploy webapp to nfs shared drive
Posted by Pid <p...@pidster.com>.
Pid wrote:
> robr wrote:
>>
>> Pid-2 wrote:
>>> Robert Rowntree wrote:
>>>> we are running a cluster of 3 nodes. we are on linux . we run tomcat
>>>> 5.5.15
>>>> and do not use the server.conf clustering . we cluster tomcat with an
>>>> external load balancer.
>>> That's a really old Tomcat, lots and lots of bug fixes since then.
>>> You should consider upgrading, at least to the latest 5.5 version.
>>>
>>> ok we will attempt upgrade.
>>>
>>>> we have tried using a context file like the example below in order to
>>>> serve
>>>> webapps from the shared drive and have experienced the following
>>>> differences
>>>> when compared to using locally attached storage for webapps:
>>>>
>>>> Symptoms:
>>>>
>>>> 1. On a startup with a new war file positioned in the root directory
>>>> for
>>>> the webapp the war file does not unpack. ./manager/list shows the app
>>>> running but it wont serve anything because war file never expanded.
>>>> 2. in 'manager app' , using the GUI request 'reload' and the war file
>>>> does not unpack
>>>> 3. in 'manager app' , using the GUI request 'undeploy' and the root
>>>> directory does not get deleted . the only thing that happens is the
>>>> context
>>>> file from ./TomcatRoot/conf/Catalina/localhost is deleted.
>>>>
>>>>
>>>> when we put the $myapp.war file in the root directory , the war file does
>>>> not expand or unpack on a tomcat startup.
>>> "root" is a special word around here; do you mean "webapps" dir?
>>>
>>> the war file was copy to the 'home' of the context ie to
>>> /mnt/nas1data/www/test. this path is on the shared drive.
>>>
>>>> ./Manager/list shows that 'myapp'
>>>> is 'running' but only the war file exists in the directoy. until we run
>>>> an
>>>> explicit 'jar -xf $myapp.jar' no unpacking occurs. Only with the explicit
>>>> command do we get the result that we expect - unpacked war file is the
>>>> result.
>>>>
>>>> Tomcat process runs under a user id that should have 'exec' permissions
>>>> in
>>>> the directory where the war file is. The context for the webapp includes
>>>> a
>>>> 'background-processor-thread' .
>>> It'll need write permissions if it's going to expand the war file.
>>>
>>> Tomcat process runs as user 'tomcat'. Tomcat user has write permissions to
>>> the directory on the share that is home to the context.
>>>
>>>> Im trying to figure out whether it is more trouble to do multiple deploys
>>>> of
>>>> the war file to each node in the cluster or whether we can have a
>>>> reliable
>>>> procedure redeploying war files to a shared drive running on NFS..
>>> Are you saying that each server is sharing access to the same webapp file?
>>>
>>> yes . In the respective ./serverHomePath/conf/Catalina/localhost/
>>> directory on the servers is a copy of the same context -
>>> /mnt/nas1data/www/test. So all servers would load classes and get
>>> resources from the share.
>>>
>>> Each Tomcat might try to expand the war file into the same shared
>>> directory, which could produce unpredictable outcomes.
>>>
>>> The assumption was that , on a redeploy, once the file system on the share
>>> was refreshed with the new copy of the files belonging to the webapp, that
>>> on the other servers , a 'stop' followed by a 'start' would result in the
>>> classloader on each respective server processing a reload of the classes
>>> without re-expanding the war. I guess that we could turn on debug in the
>>> Catalina.core package in order to verify that.
>
> You understand the point I'm trying to make?
> You've started out by saying that you want the war to expand.
>
> 1. new war is uploaded.
> 2. server1 is restarted
> 2a expanded dir is removed
> 2b war is expanded
>
> 2. server2 is restarted...
> 3. etc
>
>
> If servers other than server1 need to access the expanded war in between
> 2a and 2b then there will be a problem, as the app isn't there any more.
>
> AFAIK the war will be re-expanded for each server as the timestamp for
> the war file is the thing that is monitored. So at during each restart
> the other servers may experience problems.
Correction: unless you have deployOnStartup="false" autoDeploy="false",
reloadable="false" and are manually deploying - but even then, the loss
of service for other apps is still likely.
p
> Multiple servers sharing the same war file is Very Bad Idea. If you
> want to keep the war on a shared disk, you might at least make separate
> dirs:
>
> /mnt/nas1data/www1/test
> /mnt/nas1data/www2/test
> /mnt/nas1data/www3/test
>
>
> Alternatively write a deployment script, (using Ant, perhaps), that
> uploads the war and restarts each server separately.
>
> (Also the context.xml file shouldn't usually contain the path or docBase
> attributes, especially if it's in the expected place
> app.war/META-INF/context.xml)
>
>
> p
>
>
>>> Disk space is cheap: the amount of time you've already spent doing this
>>> has probably negated any savings in deployment that you might have been
>>> hoping for.
>>>
>>> Can you make the webapp work when it's deployed locally on each server?
>>>
>>> It works fine when deployed to each server's locally attached storage. The
>>> point was an easier deploy step given that the servers involved are a mix
>>> of OS's and that we might not want to repeat a 'redeploy ' to each server.
>>> "write once run everywhere ... " can also apply to file deployments and
>>> expanding war files in that we are interested in doing a single deployment
>>> step and having the respective servers simply pick up the change. I guess
>>> it depends on how automated you are with the 'deploy' infrastructure.
>>>
>>> thank you for the quick reply.
>>>
>>> p
>>>
>>>
>>>> --- context file for the webapp:
>>>>
>>>> <Context path="/test" docBase="/mnt/nas1data/www/test" override="true"
>>>> backgroundProcessorDelay="10" />
>>> Where is this context file placed/found?
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: deploy webapp to nfs shared drive
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: deploy webapp to nfs shared drive
>
> As far as I remember the beginning of this thread, the OP wants to have
> these applications autodeployed; which means that something in Tomcat
> has to watch these things, and notice when there's a newer copy
> available; which means directory reads, stats() etc... And this is on
> an nfs drive.
> Isn't this all a quite bad idea in terms of performance, even nowadays
> ?
Depends on the polling frequency and the number of locations that have to be polled for the autodeployment monitoring. Personally, I wouldn't use autodeploy in a production environment, even on local disks.
Haven't seen any significant performance hits using either SMB or NFS mounts on Linux for data that is primarily read-only (due to the file system cache). Network polling shouldn't be noticeably more expensive in CPU time than local polling, although the latency will obviously be much higher.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: deploy webapp to nfs shared drive
Posted by David kerber <dc...@verizon.net>.
André Warnier wrote:
> Caldarale, Charles R wrote:
>>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>>> Subject: Re: deploy webapp to nfs shared drive
>>>
>>> This would only be a problem if Tomcat's "work" directory was shared,
>>> right? Or do I have things wrong thinking that WAR files are expanded
>>> into the work directory rather than the webapps dir?
>>
>> Webapps are normally expanded into the webapps dir, not the work dir,
>> so yes, you've got it wrong. Having the same location used by
>> multiple Tomcat instances simultaneously is a timing nightmare, as
>> pid has been pointing out.
>>
> A naive question :
> As far as I remember the beginning of this thread, the OP wants to
> have these applications autodeployed; which means that something in
> Tomcat has to watch these things, and notice when there's a newer copy
> available; which means directory reads, stats() etc... And this is on
> an nfs drive.
> Isn't this all a quite bad idea in terms of performance, even nowadays ?
For a well loaded production app, yes, but for development or
lightly-loaded servers it can be very handy.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: deploy webapp to nfs shared drive
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: Re: deploy webapp to nfs shared drive
>>
>> This would only be a problem if Tomcat's "work" directory was shared,
>> right? Or do I have things wrong thinking that WAR files are expanded
>> into the work directory rather than the webapps dir?
>
> Webapps are normally expanded into the webapps dir, not the work dir, so yes, you've got it wrong. Having the same location used by multiple Tomcat instances simultaneously is a timing nightmare, as pid has been pointing out.
>
A naive question :
As far as I remember the beginning of this thread, the OP wants to have
these applications autodeployed; which means that something in Tomcat
has to watch these things, and notice when there's a newer copy
available; which means directory reads, stats() etc... And this is on
an nfs drive.
Isn't this all a quite bad idea in terms of performance, even nowadays ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: deploy webapp to nfs shared drive
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: deploy webapp to nfs shared drive
>
> This would only be a problem if Tomcat's "work" directory was shared,
> right? Or do I have things wrong thinking that WAR files are expanded
> into the work directory rather than the webapps dir?
Webapps are normally expanded into the webapps dir, not the work dir, so yes, you've got it wrong. Having the same location used by multiple Tomcat instances simultaneously is a timing nightmare, as pid has been pointing out.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: deploy webapp to nfs shared drive
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 6/16/2009 5:09 AM, Pid wrote:
> You understand the point I'm trying to make?
> You've started out by saying that you want the war to expand.
>
> 1. new war is uploaded.
> 2. server1 is restarted
> 2a expanded dir is removed
> 2b war is expanded
>
> 2. server2 is restarted...
> 3. etc
>
>
> If servers other than server1 need to access the expanded war in between
> 2a and 2b then there will be a problem, as the app isn't there any more.
This would only be a problem if Tomcat's "work" directory was shared,
right? Or do I have things wrong thinking that WAR files are expanded
into the work directory rather than the webapps dir? I use expanded WAR
files so I don't know the procedure (though expanding into the webapps
directory doesn't make much sense IMO).
> Alternatively write a deployment script, (using Ant, perhaps), that
> uploads the war and restarts each server separately.
+1
This is a good idea for uninterrupted service, too: you always have one
or more servers that are still serving requests, instead of all of them
restarting (practically) at once.
> (Also the context.xml file shouldn't usually contain the path or docBase
> attributes, especially if it's in the expected place
> app.war/META-INF/context.xml)
A context.xml file should never contain a 'path' attribute, and should
only contain a docBase when it's placed in
CATALINA_BASE/conf/Catalina/[engine]/whatever.xml.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAko3n+kACgkQ9CaO5/Lv0PABWgCcDdX5QXpb55iR1aEvXfNEZ5cn
BQgAniqgQwBlEgyDvDNjfo4Br6D8GHrh
=JATR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: deploy webapp to nfs shared drive
Posted by Pid <p...@pidster.com>.
robr wrote:
>
>
> Pid-2 wrote:
>> Robert Rowntree wrote:
>>> we are running a cluster of 3 nodes. we are on linux . we run tomcat
>>> 5.5.15
>>> and do not use the server.conf clustering . we cluster tomcat with an
>>> external load balancer.
>> That's a really old Tomcat, lots and lots of bug fixes since then.
>> You should consider upgrading, at least to the latest 5.5 version.
>>
>> ok we will attempt upgrade.
>>
>>> we have tried using a context file like the example below in order to
>>> serve
>>> webapps from the shared drive and have experienced the following
>>> differences
>>> when compared to using locally attached storage for webapps:
>>>
>>> Symptoms:
>>>
>>> 1. On a startup with a new war file positioned in the root directory
>>> for
>>> the webapp the war file does not unpack. ./manager/list shows the app
>>> running but it wont serve anything because war file never expanded.
>>> 2. in 'manager app' , using the GUI request 'reload' and the war file
>>> does not unpack
>>> 3. in 'manager app' , using the GUI request 'undeploy' and the root
>>> directory does not get deleted . the only thing that happens is the
>>> context
>>> file from ./TomcatRoot/conf/Catalina/localhost is deleted.
>>>
>>>
>>> when we put the $myapp.war file in the root directory , the war file does
>>> not expand or unpack on a tomcat startup.
>> "root" is a special word around here; do you mean "webapps" dir?
>>
>> the war file was copy to the 'home' of the context ie to
>> /mnt/nas1data/www/test. this path is on the shared drive.
>>
>>> ./Manager/list shows that 'myapp'
>>> is 'running' but only the war file exists in the directoy. until we run
>>> an
>>> explicit 'jar -xf $myapp.jar' no unpacking occurs. Only with the explicit
>>> command do we get the result that we expect - unpacked war file is the
>>> result.
>>>
>>> Tomcat process runs under a user id that should have 'exec' permissions
>>> in
>>> the directory where the war file is. The context for the webapp includes
>>> a
>>> 'background-processor-thread' .
>> It'll need write permissions if it's going to expand the war file.
>>
>> Tomcat process runs as user 'tomcat'. Tomcat user has write permissions to
>> the directory on the share that is home to the context.
>>
>>> Im trying to figure out whether it is more trouble to do multiple deploys
>>> of
>>> the war file to each node in the cluster or whether we can have a
>>> reliable
>>> procedure redeploying war files to a shared drive running on NFS..
>> Are you saying that each server is sharing access to the same webapp file?
>>
>> yes . In the respective ./serverHomePath/conf/Catalina/localhost/
>> directory on the servers is a copy of the same context -
>> /mnt/nas1data/www/test. So all servers would load classes and get
>> resources from the share.
>>
>> Each Tomcat might try to expand the war file into the same shared
>> directory, which could produce unpredictable outcomes.
>>
>> The assumption was that , on a redeploy, once the file system on the share
>> was refreshed with the new copy of the files belonging to the webapp, that
>> on the other servers , a 'stop' followed by a 'start' would result in the
>> classloader on each respective server processing a reload of the classes
>> without re-expanding the war. I guess that we could turn on debug in the
>> Catalina.core package in order to verify that.
You understand the point I'm trying to make?
You've started out by saying that you want the war to expand.
1. new war is uploaded.
2. server1 is restarted
2a expanded dir is removed
2b war is expanded
2. server2 is restarted...
3. etc
If servers other than server1 need to access the expanded war in between
2a and 2b then there will be a problem, as the app isn't there any more.
AFAIK the war will be re-expanded for each server as the timestamp for
the war file is the thing that is monitored. So at during each restart
the other servers may experience problems.
Multiple servers sharing the same war file is Very Bad Idea. If you
want to keep the war on a shared disk, you might at least make separate
dirs:
/mnt/nas1data/www1/test
/mnt/nas1data/www2/test
/mnt/nas1data/www3/test
Alternatively write a deployment script, (using Ant, perhaps), that
uploads the war and restarts each server separately.
(Also the context.xml file shouldn't usually contain the path or docBase
attributes, especially if it's in the expected place
app.war/META-INF/context.xml)
p
>> Disk space is cheap: the amount of time you've already spent doing this
>> has probably negated any savings in deployment that you might have been
>> hoping for.
>>
>> Can you make the webapp work when it's deployed locally on each server?
>>
>> It works fine when deployed to each server's locally attached storage. The
>> point was an easier deploy step given that the servers involved are a mix
>> of OS's and that we might not want to repeat a 'redeploy ' to each server.
>> "write once run everywhere ... " can also apply to file deployments and
>> expanding war files in that we are interested in doing a single deployment
>> step and having the respective servers simply pick up the change. I guess
>> it depends on how automated you are with the 'deploy' infrastructure.
>>
>> thank you for the quick reply.
>>
>> p
>>
>>
>>> --- context file for the webapp:
>>>
>>> <Context path="/test" docBase="/mnt/nas1data/www/test" override="true"
>>> backgroundProcessorDelay="10" />
>> Where is this context file placed/found?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: deploy webapp to nfs shared drive
Posted by robr <ro...@yahoo.com>.
Pid-2 wrote:
>
> Robert Rowntree wrote:
>> we are running a cluster of 3 nodes. we are on linux . we run tomcat
>> 5.5.15
>> and do not use the server.conf clustering . we cluster tomcat with an
>> external load balancer.
>
> That's a really old Tomcat, lots and lots of bug fixes since then.
> You should consider upgrading, at least to the latest 5.5 version.
>
> ok we will attempt upgrade.
>
>> we have tried using a context file like the example below in order to
>> serve
>> webapps from the shared drive and have experienced the following
>> differences
>> when compared to using locally attached storage for webapps:
>>
>> Symptoms:
>>
>> 1. On a startup with a new war file positioned in the root directory
>> for
>> the webapp the war file does not unpack. ./manager/list shows the app
>> running but it wont serve anything because war file never expanded.
>> 2. in 'manager app' , using the GUI request 'reload' and the war file
>> does not unpack
>> 3. in 'manager app' , using the GUI request 'undeploy' and the root
>> directory does not get deleted . the only thing that happens is the
>> context
>> file from ./TomcatRoot/conf/Catalina/localhost is deleted.
>>
>>
>> when we put the $myapp.war file in the root directory , the war file does
>> not expand or unpack on a tomcat startup.
>
> "root" is a special word around here; do you mean "webapps" dir?
>
> the war file was copy to the 'home' of the context ie to
> /mnt/nas1data/www/test. this path is on the shared drive.
>
>> ./Manager/list shows that 'myapp'
>> is 'running' but only the war file exists in the directoy. until we run
>> an
>> explicit 'jar -xf $myapp.jar' no unpacking occurs. Only with the explicit
>> command do we get the result that we expect - unpacked war file is the
>> result.
>>
>> Tomcat process runs under a user id that should have 'exec' permissions
>> in
>> the directory where the war file is. The context for the webapp includes
>> a
>> 'background-processor-thread' .
>
> It'll need write permissions if it's going to expand the war file.
>
> Tomcat process runs as user 'tomcat'. Tomcat user has write permissions to
> the directory on the share that is home to the context.
>
>> Im trying to figure out whether it is more trouble to do multiple deploys
>> of
>> the war file to each node in the cluster or whether we can have a
>> reliable
>> procedure redeploying war files to a shared drive running on NFS..
>
> Are you saying that each server is sharing access to the same webapp file?
>
> yes . In the respective ./serverHomePath/conf/Catalina/localhost/
> directory on the servers is a copy of the same context -
> /mnt/nas1data/www/test. So all servers would load classes and get
> resources from the share.
>
> Each Tomcat might try to expand the war file into the same shared
> directory, which could produce unpredictable outcomes.
>
> The assumption was that , on a redeploy, once the file system on the share
> was refreshed with the new copy of the files belonging to the webapp, that
> on the other servers , a 'stop' followed by a 'start' would result in the
> classloader on each respective server processing a reload of the classes
> without re-expanding the war. I guess that we could turn on debug in the
> Catalina.core package in order to verify that.
>
> Disk space is cheap: the amount of time you've already spent doing this
> has probably negated any savings in deployment that you might have been
> hoping for.
>
> Can you make the webapp work when it's deployed locally on each server?
>
> It works fine when deployed to each server's locally attached storage. The
> point was an easier deploy step given that the servers involved are a mix
> of OS's and that we might not want to repeat a 'redeploy ' to each server.
> "write once run everywhere ... " can also apply to file deployments and
> expanding war files in that we are interested in doing a single deployment
> step and having the respective servers simply pick up the change. I guess
> it depends on how automated you are with the 'deploy' infrastructure.
>
> thank you for the quick reply.
>
> p
>
>
>> --- context file for the webapp:
>>
>> <Context path="/test" docBase="/mnt/nas1data/www/test" override="true"
>> backgroundProcessorDelay="10" />
>
> Where is this context file placed/found?
>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/deploy-webapp-to-nfs-shared-drive-tp24028367p24039266.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: deploy webapp to nfs shared drive
Posted by Pid <p...@pidster.com>.
Robert Rowntree wrote:
> we are running a cluster of 3 nodes. we are on linux . we run tomcat 5.5.15
> and do not use the server.conf clustering . we cluster tomcat with an
> external load balancer.
That's a really old Tomcat, lots and lots of bug fixes since then.
You should consider upgrading, at least to the latest 5.5 version.
> we have tried using a context file like the example below in order to serve
> webapps from the shared drive and have experienced the following differences
> when compared to using locally attached storage for webapps:
>
> Symptoms:
>
> 1. On a startup with a new war file positioned in the root directory for
> the webapp the war file does not unpack. ./manager/list shows the app
> running but it wont serve anything because war file never expanded.
> 2. in 'manager app' , using the GUI request 'reload' and the war file
> does not unpack
> 3. in 'manager app' , using the GUI request 'undeploy' and the root
> directory does not get deleted . the only thing that happens is the context
> file from ./TomcatRoot/conf/Catalina/localhost is deleted.
>
>
> when we put the $myapp.war file in the root directory , the war file does
> not expand or unpack on a tomcat startup.
"root" is a special word around here; do you mean "webapps" dir?
> ./Manager/list shows that 'myapp'
> is 'running' but only the war file exists in the directoy. until we run an
> explicit 'jar -xf $myapp.jar' no unpacking occurs. Only with the explicit
> command do we get the result that we expect - unpacked war file is the
> result.
>
> Tomcat process runs under a user id that should have 'exec' permissions in
> the directory where the war file is. The context for the webapp includes a
> 'background-processor-thread' .
It'll need write permissions if it's going to expand the war file.
> Im trying to figure out whether it is more trouble to do multiple deploys of
> the war file to each node in the cluster or whether we can have a reliable
> procedure redeploying war files to a shared drive running on NFS..
Are you saying that each server is sharing access to the same webapp file?
Each Tomcat might try to expand the war file into the same shared
directory, which could produce unpredictable outcomes.
Disk space is cheap: the amount of time you've already spent doing this
has probably negated any savings in deployment that you might have been
hoping for.
Can you make the webapp work when it's deployed locally on each server?
p
> --- context file for the webapp:
>
> <Context path="/test" docBase="/mnt/nas1data/www/test" override="true"
> backgroundProcessorDelay="10" />
Where is this context file placed/found?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org