You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ben Stringer <be...@burbong.com> on 2007/06/28 02:06:33 UTC

Clean webapp redeploy with tomcat down

Hi all,

I am running tomcat 5.5 on linux (RHEL 4), IBM JDK 1.4.2 SR7, and see an
unusual behaviour that I am hoping is due to a gap in my knowledge.

When redeploying webapps, I have preferred a procedure where tomcat is
stopped, all database, LDAP connections from the app are observed to
have closed, a new webapp is deployed, then tomcat is restarted, and
automatically unpacks the new WAR.

However I have seen cases where setting from the previous WAR (usually
these are changed JDBC strings) are maintained in the new deployment. I
have modified the procedure to also remove the "temp" and "work"
directories whilst tomcat is down, but still see the same behaviour.

Is there some other place the JDBC strings from the previous webapp
would be cached? The problem does not occur if the webapp is deployed on
a running tomcat, and this is a reasonable solution, however I'd like to
understand why the procedure with tomcat stopped has this issue.

Appreciate any insights.

Thanks, Ben


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Clean webapp redeploy with tomcat down

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ben Stringer [mailto:ben@burbong.com] 
> Subject: Re: Clean webapp redeploy with tomcat down
> 
> In one case the database was migrated to a new server.
> When the WAR with the new JDBC string included was
> deployed, the app continued to attempt to connect to
> the old server.

DNS problem?  Spurious entry in the system's hosts file?  Misconfigured
router?

 - 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.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Clean webapp redeploy with tomcat down

Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message ----- 
From: "Ben Stringer" <be...@burbong.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Thursday, June 28, 2007 4:08 PM
Subject: Re: Clean webapp redeploy with tomcat down


> On Thu, 2007-06-28 at 08:16 +0200, Johnny Kewl wrote:
>> Ben, what is it exactly that you see, does it continue to use a different
>> dB?
>> Or perhaps it doesnt pick up a table modification?
>
> Hi Johnny,
>
> In one case the database was migrated to a new server. When the WAR with
> the new JDBC string included was deployed, the app continued to attempt
> to connect to the old server.

Ben I dont think, its something wrong with TC, but I have seen the 
behaviour, and it has to do with Deployer and the Dev environment, in 
particular Netbeans.
Just check the following is not happening.
When Netbeans runs a War in dev environment, it takes control of TC, and 
does not install the WAR in Tomcat, it tells TC to use the Build folder.
If you then drop a WAR in, NB does not let go, but the WAR appears to run, 
however its still using the DEV base files.
If you have been testing from the dev environment, its a good habit to 
delete the conf/Catalina/host/webappcontext.xml, then drop the WAR in, or if 
you get the funny again, have a look at it and it will show you which base 
is running, I'm guessing its still the connected to the DEV base.
Its not really a bug, its two deployers battling for ownership of the 
context path.

> In another case, the min and max connection pooling settings were
> increased, but did not take affect.
>
> Both cases were related to the JDBC connection settings, rather than a
> table on the database.
>
> Cheers, Ben
>
>>
>> ----- Original Message ----- 
>> From: "Ben Stringer" <be...@burbong.com>
>> To: <us...@tomcat.apache.org>
>> Sent: Thursday, June 28, 2007 2:06 AM
>> Subject: Clean webapp redeploy with tomcat down
>>
>>
>> > Hi all,
>> >
>> > I am running tomcat 5.5 on linux (RHEL 4), IBM JDK 1.4.2 SR7, and see 
>> > an
>> > unusual behaviour that I am hoping is due to a gap in my knowledge.
>> >
>> > When redeploying webapps, I have preferred a procedure where tomcat is
>> > stopped, all database, LDAP connections from the app are observed to
>> > have closed, a new webapp is deployed, then tomcat is restarted, and
>> > automatically unpacks the new WAR.
>> >
>> > However I have seen cases where setting from the previous WAR (usually
>> > these are changed JDBC strings) are maintained in the new deployment. I
>> > have modified the procedure to also remove the "temp" and "work"
>> > directories whilst tomcat is down, but still see the same behaviour.
>> >
>> > Is there some other place the JDBC strings from the previous webapp
>> > would be cached? The problem does not occur if the webapp is deployed 
>> > on
>> > a running tomcat, and this is a reasonable solution, however I'd like 
>> > to
>> > understand why the procedure with tomcat stopped has this issue.
>> >
>> > Appreciate any insights.
>> >
>> > Thanks, Ben
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To start a new topic, e-mail: users@tomcat.apache.org
>> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> > For additional commands, e-mail: users-help@tomcat.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Clean webapp redeploy with tomcat down

Posted by Ben Stringer <be...@burbong.com>.
On Thu, 2007-06-28 at 08:16 +0200, Johnny Kewl wrote:
> Ben, what is it exactly that you see, does it continue to use a different 
> dB?
> Or perhaps it doesnt pick up a table modification?

Hi Johnny,

In one case the database was migrated to a new server. When the WAR with
the new JDBC string included was deployed, the app continued to attempt
to connect to the old server.

In another case, the min and max connection pooling settings were
increased, but did not take affect.

Both cases were related to the JDBC connection settings, rather than a
table on the database.

Cheers, Ben

> 
> ----- Original Message ----- 
> From: "Ben Stringer" <be...@burbong.com>
> To: <us...@tomcat.apache.org>
> Sent: Thursday, June 28, 2007 2:06 AM
> Subject: Clean webapp redeploy with tomcat down
> 
> 
> > Hi all,
> >
> > I am running tomcat 5.5 on linux (RHEL 4), IBM JDK 1.4.2 SR7, and see an
> > unusual behaviour that I am hoping is due to a gap in my knowledge.
> >
> > When redeploying webapps, I have preferred a procedure where tomcat is
> > stopped, all database, LDAP connections from the app are observed to
> > have closed, a new webapp is deployed, then tomcat is restarted, and
> > automatically unpacks the new WAR.
> >
> > However I have seen cases where setting from the previous WAR (usually
> > these are changed JDBC strings) are maintained in the new deployment. I
> > have modified the procedure to also remove the "temp" and "work"
> > directories whilst tomcat is down, but still see the same behaviour.
> >
> > Is there some other place the JDBC strings from the previous webapp
> > would be cached? The problem does not occur if the webapp is deployed on
> > a running tomcat, and this is a reasonable solution, however I'd like to
> > understand why the procedure with tomcat stopped has this issue.
> >
> > Appreciate any insights.
> >
> > Thanks, Ben
> >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> > 
> 
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Clean webapp redeploy with tomcat down

Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
Ben, what is it exactly that you see, does it continue to use a different 
dB?
Or perhaps it doesnt pick up a table modification?

----- Original Message ----- 
From: "Ben Stringer" <be...@burbong.com>
To: <us...@tomcat.apache.org>
Sent: Thursday, June 28, 2007 2:06 AM
Subject: Clean webapp redeploy with tomcat down


> Hi all,
>
> I am running tomcat 5.5 on linux (RHEL 4), IBM JDK 1.4.2 SR7, and see an
> unusual behaviour that I am hoping is due to a gap in my knowledge.
>
> When redeploying webapps, I have preferred a procedure where tomcat is
> stopped, all database, LDAP connections from the app are observed to
> have closed, a new webapp is deployed, then tomcat is restarted, and
> automatically unpacks the new WAR.
>
> However I have seen cases where setting from the previous WAR (usually
> these are changed JDBC strings) are maintained in the new deployment. I
> have modified the procedure to also remove the "temp" and "work"
> directories whilst tomcat is down, but still see the same behaviour.
>
> Is there some other place the JDBC strings from the previous webapp
> would be cached? The problem does not occur if the webapp is deployed on
> a running tomcat, and this is a reasonable solution, however I'd like to
> understand why the procedure with tomcat stopped has this issue.
>
> Appreciate any insights.
>
> Thanks, Ben
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org