Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X_JWMH_OUTBOUND: true
X_JWMH_FLAG: $label3
X_JWMH_TGTFOLDER: Apache Forums.Tomcat Users
X-Processor-Transport: true
X-UserIsAuth: true
X-MIME-Autoconverted: from 8bit to quoted-printable by Apache JAMES
Received: from cpe-66-68-42-68.austin.res.rr.com (EHLO [192.168.0.11]) ([66.68.42.68])
          by mx2.jwmhosting.com (JAMES SMTP Server ) with ESMTPA ID 11649696
          for <users@tomcat.apache.org>;
          Wed, 23 Aug 2017 11:29:45 -0500 (CDT)
To: Tomcat Users List <users@tomcat.apache.org>
From: Jerry Malcolm <techstuff@malcolms.com>
Subject: Refreshing webapps slows server
Message-ID: <f36433ea-e29d-9ee0-ba17-ecb1ca31a373@malcolms.com>
Date: Wed, 23 Aug 2017 11:29:43 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
Content-Language: en-US
archived-at: Wed, 23 Aug 2017 16:30:03 -0000

I have a very weird situation.  I have a  staging server and a 
production server running on the same instance of TC (8.0).  When I'm 
doing development and testing on the staging server, I'm often replacing 
jar files and JSPs in the various webapps running on the staging server 
(I don't reupload full WAR files each time... just incremental jar/jsp 
changes).  TC recognizes the updated jar files and reloads.  Both 
production and development sites continue to function (including using 
the new updated jars, etc).  But over time, Tomcat starts getting slower 
and slower in response time, sometimes hitting an OutofMemory error.  
Response time on a request goes from milliseconds to 20+ seconds.  
Bouncing TC fixes everything.

This is somewhat circumstantial.  But TC will run fine for days and 
never hits OutofMemory situations.  But as soon as I start replacing 
webapp jar files, things start going bad.  So it appears that the issue 
is caused by replacing jar files.

Is this a recognized situation?  I don't want to have to bounce the 
production site every time I refresh the staging code.  But I need to 
test updates on the staging site on the same server.  Are there 
alternatives to keep this slowdown from occurring? Suggestions?

Thx.

Jerry


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