Ive done some more research into this problem with my co developer, and we have a question. Is it possible that memory leaks would cause tomcat to crash? Silly question I know, but heres technically what the situation is. We did not add code to shut down all threads when application is undeployed through tomcat manager. When undeploying and redeploying we cause memory leaks due to our application. Now, I guess the real question is, we seem to always deploy it fine, but randomly at some point during the night it will crash, and we only know that from checking next morning. We have nothing logged that indicates why. Would memory leaks cause it to crash randomly even though nothing is trying to connect to it, yet it would seem to deploy fine? Could that be the issue we are seeing? Is there any specific class to debug in logging.properties that might indicate whats going on? I added that line you guys mentioned about setting log level to DEBUG from that class loader class, but it hasnt crashed since then....
On Thu, Apr 3, 2014 at 12:06 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mark, > > On 4/2/14, 5:20 PM, Mark Eggers wrote: > > Chris, > > > > On 4/2/2014 1:54 PM, Christopher Schultz wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> > >> Mark, > >> > >> On 4/2/14, 4:30 PM, Mark Eggers wrote: > >>> Chris, > >>> > >>> On 4/2/2014 1:05 PM, Christopher Schultz wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >>>> > >>>> Chuck, > >>>> > >>>> On 4/2/14, 8:21 AM, Caldarale, Charles R wrote: > >>>>>> From: Elias Kopsiaftis [mailto:yemi...@gmail.com] > >>>>>> Subject: tomcat randomly undeploys and redeploys the > >>>>>> applications > >>>>> > >>>>>> I deploy the application, then in the log file > >>>>>> catalina.out i get many messages from WebappClassLoader > >>>>>> clearReferencesThreads saying threads appear to have > >>>>>> started but have failed to stop > >>>>> > >>>>> This is an indication that your webapp is not managing its > >>>>> threads properly. > >>>>> > >>>>>> then finally, Ill get a message from HostConfig > >>>>>> checkResources that says its undeploying the context, > >>>>>> and then it redeploys. > >>>>> > >>>>> This is sometimes caused by incorrect timestamps on the > >>>>> bits of the webapp that Tomcat monitors, or an incorrect > >>>>> clock setting on the system Tomcat is running on. The > >>>>> mismatch makes it appear that the webapp is being updated > >>>>> continuously. > >>>> > >>>> I've found that in development, a single update can cause > >>>> Tomcat to go into a loop of redeployments, re-deploying my > >>>> web application every few seconds or so. If I let it go, it > >>>> does finally stop reloading and settle down. > >>>> > >>> > >>> Can you describe your development environment a little bit, > >>> and any thoughts as to what might trigger this loop of > >>> redeployments? > >> > >> I use Eclipse for development, but our "real" build process is > >> ant-based. We have some watched resources configured outside the > >> default (stuff like Struts config files, etc.). > >> > > > > Ah, makes sense. > > > >> When I do a build while Tomcat is running, usually I get one > >> webapp reload, but sometimes I get a series of reloads. It > >> usually gets so irritating (our webapp takes about 10 seconds to > >> reload) that I just kill Tomcat and immediately restart it. It > >> starts up once and all is well after that. > >> > > > > Yep, and in the process more files are copied about, and that > > triggers another reload. > > > > Fun, fun. > > No, the deployment update takes like one or two seconds. It's usually > something like copying less than 10 class files or whatever. It's > nearly instantaneous. Whatever happens, it's not because I'm updating > files during the reload. I could understand that situation. > > What I observe is that I update my application, I wait maybe 10 > seconds, and then Tomcat reloads my application multiple times before > I just kill it. > > >>> I've not seen this, but it could explain some issues some the > >>> developers I support are seeing. > >> > >> It definitely happens, and I never remember to enable the DEBUG > >> logging to find out what resource it thinks has been updated > >> until after it happens, at which point I just don't care. Perhaps > >> I should enable it right now :) > >> > >> - -chris > > > > I've managed to make this happen in my environment now (NetBeans > > 7.4, Maven 3.2.1, Tomcat 7.0.42 - all will be upgraded soon). I > > just needed an application that takes a bit longer to load. I only > > managed to trigger two reloads, so it's not much of an issue. > > > > Maybe look at adding the backgroundProcessorDelay attribute to the > > context? I don't know what would happen if the context got a string > > of reload requests within the delay interval. Would it queue them > > up one after the other, or would it just execute one? > > I think it's more important to see what file(s) Tomcat thinks is(are) > being updated. I wonder if it's the same file, or if there's some > weird timestamp issue happening. Perhaps there is even some kind of > edge case where a resource's last-modified date isn't being updated > properly. > > In most cases, Tomcat reloads my application a single time, as > expected. These reload-storms are fairly rare. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTPYcLAAoJEBzwKT+lPKRYf/gQAKhUNIp0yIP24g6fctOppPGC > 0WbacCWGaJwC9Xbuh/lNqtYRZck2943+rOZwOw4sBfwxox3dlVYGl+NHj0C4NRyW > KJmH11v5gO59Di7S4NZeYGlHpbYWSZt/2HiMZAVQ6zElXN5qkSEa5WbjXJJsduSe > FHD6RFLST7pvlbOuEj8L/+MldsflYTe7Mu5CykBK52GLZGMAYTFYWqcs6nrsscxc > ZWEKAt1QU1barvojnoZjk4pZksihi/QwOmCJ1a+rHWUZPmtzp/9gdTon47WHDcXU > NVEQLOHJgtolJI2XYMVXFZPVOEeD80PWdQ+aIUAozOR954odw9RcZRz71EiNAagB > YBImgFi0zFNwVKivi4yqKHGex8LPj6qGuDI2Nd48Za4s6gN90fpHwpYFzrq3dnnv > ep7Jf1qHNiGc70s//TH8iKZToCkN/N2Sythlv729NEFGdXBkn0Ph8RVhPmxiYiwu > WrIXrk875m2241QBubcuaNFnPPmNA2cj0IkHB8QDM+35wUI40sx+vtMvLV3U674O > JBATY5Oiq26jj585OAsNJJsNY1y33rkH0tqZNEPTYUfqSW4FUxHe0J6TWf7CMujF > sPjQqk1kXawsyNJNeGqKxUqW6LHvo+dX40/FmgAl4llkOCU9DFXxdhZVBg14UQdC > OeWlyGTxwovZZEdJJqtO > =r81a > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
