I'm confused by the suggestion below -- the farm depoyer is entirely based on the appearance or disappearance of a .war file in the watch directory of the master tomcat node. No URL-based manager should come into play here, and using the standard manager (/manager/html) on such an application would likely result in conflicts or confusion.
I was hoping to avoid having to visit some URL, or copy some file, for each member of the cluster. The whole point of the farm deployer, or so I thought, was to deploy, undeploy or redeploy from one and only one spot, and let the cluster (3 machines today, maybe 4 tomorrow and 10 in 2 years...) worry about getting the message out. My original question (request) was for a URL-based manager, like /manager/html, except which worked on the cluster. I.e., something like /farm-manager/html, which only appears on the master node, but functions identically to /manager/html from the outside, preserving the view that the cluster is a single entity. My experience suggests that the farm deployer is not 100% reliable (for me) at this time, perhaps it is the mixed OS, perhaps network lag -- not sure what. I have an existing, workable solution that works off of a list of tomcat servers (as a property), and uses the <foreach...> task (ant-contrib) to undeploy-then-deploy for each tomcat in the list. The danger in a production environment is that there are incompatible changes to objects on the session which would cause some strange failure during session failover. Those can be mitigated by upgrading during off-peak hours or planned maintenance, and/or limiting changes to session objects. (Just a historical note -- my company's business turns on making changes to various reporting screens on a weekly basis. So once a week we deploy a new war with all the approved changes for the week. We are at the mercy of state reporting requirement changes, and state mandated deadlines, so we don't have a lot of flexibility in when we do releases or updates. The nature of the business definitely exaggerates any warts, bumps or blemishes.) Tim -----Original Message----- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 10:08 AM To: Tomcat Users List Subject: Re: Ant deploy task and cluster-wide (farm) deployment Good Point Tim- There is a difference between 'copying' and 'deploying' which means you copied the war to Tomcat / went to manager module and did a restart copying - (always safer to delete the old war and then copy in the new war) deploying - You want to look at URL utilities like curl to automate the task to open the axis servlet URL such as http://localhost:8080/manager/html/reload?path=/axis Does this help you? Martin -- ********************************************************************* This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. ----- Original Message ----- From: "Tim Lucia" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" <users@tomcat.apache.org>; "'Martin Gainty'" <[EMAIL PROTECTED]> Sent: Monday, May 22, 2006 9:33 AM Subject: RE: Ant deploy task and cluster-wide (farm) deployment > Well, given that exec cp would be the same as my running it from the shell, > and I've already observed that does not work (nor does it work from the > explorer window(s)), I would guess that it won't work if forked-and-execed > from ant. > > The question still remains - How do I know for sure that delete and copy are > "done" and the app is undeployed / redeployed? With the deploy task, I know > that the undeploy is complete when the http request completes. I was hoping > there could be a similar mechanism in the works for the cluster model. I > think it would be quite beneficial. > > I may have a few hours of spare time this week and if I do, I will attempt > to characterize exactly what happens, how often, and when. Or maybe I > should attempt to find some options in Samba that mitigate this. > > Tim > > > -----Original Message----- > From: Martin Gainty [mailto:[EMAIL PROTECTED] > Sent: Monday, May 22, 2006 8:53 AM > To: Tomcat Users List > Subject: Re: Ant deploy task and cluster-wide (farm) deployment > > As I believe you have come across a Samba specific issue with copy task The > intelligent and wonderfully talented folks at Bowstreet recommend using exec > with copy over using Ant copy task (apparently preserving permissions and > identifying which source/target file is 'older' would be accomplished using > exec vs using ant copy) > > http://72.14.209.104/search?q=cache:ITQuwFOAUAAJ:buzz.bowstreet.com/post.asp > %3Fmethod%3DReplyQuote%26REPLY_ID%3D506%26TOPIC_ID%3D272%26FORUM_ID%3D15+%22 > ANT+copy%22+and+%22samba+mount%22&hl=en&gl=us&ct=clnk&cd=1 > > Does this answer your question? > Martin -- > ********************************************************************* > This email message and any files transmitted with it contain confidential > information intended only for the person(s) to whom this email message is > addressed. If you have received this email message in error, please notify > the sender immediately by telephone or email and destroy the original > message without making a copy. Thank you. > > > > ----- Original Message ----- > From: "Tim Lucia" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" <users@tomcat.apache.org>; "'Martin Gainty'" > <[EMAIL PROTECTED]> > Sent: Sunday, May 21, 2006 8:49 PM > Subject: RE: Ant deploy task and cluster-wide (farm) deployment > > >> Push or pull, when it gets there, it gets there correctly (md5sum-s > match). >> The problem, I think, is that the file appears in the file system before > it >> is received in its entirety. I don't know why -- maybe the nature of > samba >> is to write, close, open-for-append, ... ? If I copy FROM Linux ("pull") >> then I do not have this problem, it's only when pushing to the linux file >> system mounted via samba from Windows. I've tried this numerous times, >> because I have a strong desire to automate the build and deploy process as >> much as possible -- saves me from having to do it myself ;-) I haven't > 100% >> isolated the exact circumstances. >> >> Even if the push model worked (i.e., ant copy tasks) how can I know for >> certain when the old is undeployed and when the new is deployed? And >> speaking of that, should I simply be able to overwrite and have it > redeploy? >> I've not seen that work -- sometimes it does, sometimes it doesn't, and >> because it is a push, it suffers from the sample problem as above. >> >> For the record, the source is a Windows XP and/or W2K3 NTFS and the target >> is RHEL V.4. Tomcat 5.5.12, JDK 1.5_05. >> >> Tim >> >> -----Original Message----- >> From: Martin Gainty [mailto:[EMAIL PROTECTED] >> Sent: Sunday, May 21, 2006 8:09 PM >> To: Tomcat Users List >> Subject: Re: Ant deploy task and cluster-wide (farm) deployment >> >> Tim- >> >> I found the majority of transfer programs transfer text not binary..this > is >> especially problematic when transferring from Windows to Nix >> As a war is a binary I would make sure that the transferring program is > not >> interjecting LF with CR and or treating the transferred war unit as text >> >> Martin - >> >> This email message and any files transmitted with it contain confidential >> information intended only for the person(s) to whom this email message is >> addressed. If you have received this email message in error, please > notify >> the sender immediately by telephone or email and destroy the original >> message without making a copy. Thank you. >> >> ----- Original Message ----- >> From: "Tim Lucia" <[EMAIL PROTECTED]> >> To: "'Tomcat Users List'" <users@tomcat.apache.org> >> Sent: Sunday, May 21, 2006 5:06 PM >> Subject: RE: Ant deploy task and cluster-wide (farm) deployment >> >> >>>I have observed that if I build on windows, and copy FROM windows to > Linux, >>> Tomcat will prematurely begin transferring the war file to the rest of > the >>> cluster. The master tomcat will end up with a correct war file, and the >>> other will get a corrupt or truncated one. >>> >>> Also, there is no synchronous way to remove the old war, know that it is >>> undeployed from all tomcats in the cluster, and then you know you can >>> deploy >>> the new war. I guess I could have it sleep for 30 seconds or so, but > even >>> that is no guarantee. I haven't found that copy with overwrite >>> consistently >>> triggers the copy. >>> >>> I'm guessing this is a samba issue, but due to circumstances beyond my >>> control, our build machine is running windows and I can't change it. At >>> least with the manager application, when control returns to ant, the app >>> is >>> definitely (and reliably) undeployed. >>> >>> Tim >>> >>> >>> -----Original Message----- >>> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] >>> Sent: Sunday, May 21, 2006 7:55 AM >>> To: Tomcat Users List >>> Subject: Re: Ant deploy task and cluster-wide (farm) deployment >>> >>> yes, farm deployment is triggered by simplying copying a WAR into the >>> "watch" directory, with ant that would be using the copy task >>> Filip >>> >>> >>> Tim Lucia wrote: >>>> Is it possible to deploy to a cluster using the deploy task? (i.e., can >>> it >>>> be done using /manager/html?) I think not (I can't find any way to do >>> it.) >>>> >>>> >>>> If no, are there any plans to support this in the future? >>>> >>>> I ask because I have found that production re-deployment is an > unreliable >>>> process when you have to rely on deleting and copying war files across a >>>> network share. I'd like to avoid having to keep a list of cluster >>>> members >>>> around in order to undeploy and deploy to each one. >>>> >>>> Thanks, >>>> Tim >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
