RuntimeException when running Servlet: Tomcat restarting on its own - java

I am new to servlets and using Tomcat version 7.0.34 (we were instructed to use this version only). My problem is that the Tomcat seems to restart at some point of time, this occurs when I don't interact with the servlet for some time. I see the following:
.
Further when I tried debugging through eclipse I see the following entries in the debug window:
Daemon Thread [http-bio-80-exec-1] (Suspended (exception RuntimeException))
ThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: not available
ThreadPoolExecutor$Worker.run() line: not available
TaskThread(Thread).run() line: not available
And this in console:
SEVERE: The web application [/csj] is still processing a request that has yet to finish. This is very likely to create a memory leak. You can control the time allowed for requests to finish by using the unloadDelay attribute of the standard Context implementation.
Okt 03, 2016 1:39:39 AM org.apache.catalina.core.StandardContext reload
INFO: Reloading Context with name [/csj] is completed
I want to know the reason why Tomcat is restarting. If I keep clicking the buttons with no delays, then this problem is not seen.
I tried looking here: Tomcat showing this error "This is very likely to create a memory leak". How to resolve this issue? and here: The web application [ROOT] is still processing a request that has yet to finish. [Tomcat] but I am at loss to understand.
It seems this problem is solved in newer version of Tomcat as per this:http://wiki.apache.org/tomcat/MemoryLeakProtection . Nevertheless I would like to understand what is this problem about.
Edit: Using eclipse-mars

Your tomcat is configured for "hot deploy" i.e. if you change code, tomcat will incorporate new code without a server restart. This can be configured on tomcat, or in eclipse. You can go there and disable this as it is actually a headache and consumes more time, and sometimes doesn't work correctly.
Tomcat loads each webapp using a separate classloader. It monitors your files for changes, and if a change happens, it unloads your webapp by destroying the classloader, and loads again using a new class loader. When this is happening, you will see all kinds of logs as you mentioned.
For eclipse configuration, see here
For tomcat configuration, see here
Also, from Tomcat docs, read this

In server.xml, set reloadable="false".
From https://tomcat.apache.org/tomcat-5.5-doc/config/context.html
Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. That's why the default setting for this attribute is false. You can use the Manager web application, however, to trigger reloads of deployed applications on demand.

Related

Skip deploying or stop web application if servlet context initialization fails

In our project, we have several Spring-based modules which are deployed on WAS as web applications. We need to skip deployment, or stop a module if its Spring context initialization fails (i.e. ContextLoaderListener#contextInitialized or DispatcherServlet#init throws an exception). Now, if such happens, app is got deployed and starts, but returns HTTP 500 for any request.
Websphere 8.5.5
Related question: https://stackoverflow.com/a/272747/3459206
This APAR seems to be relevant:
https://www-01.ibm.com/support/docview.wss?uid=swg1PI58875
From the APAR text:
Listener exceptions typically should not stop the application
from starting up for service. However, some applications depend
on their listeners to do the necessary setup before the
application is started for service. Such applications prefer to
stop the application from starting up when there is any
exception in their listeners.
Problem conclusion
The WebContainer Container code was modified to provide an
option to stop the application when there is any listener
exception during the application starting up process.
A new WebContainer custom property needs to be set to enable the
behavior provided by this APAR:
For Full Profiles
com.ibm.ws.webcontainer.stopappstartuponlistenerexception = true
(default is false)
For Liberty Profile
stopappstartuponlistenerexception=true
The fix for this APAR is currently targeted for inclusion in
WebSphere Application Server fix packs 8.5.5.11 and 9.0.0.2,
and Liberty 16.0.0.3
See the APAR link for additional information.
You can use jenkins + maven.
Add the part you need to check under your test like junit.
Then if this module do not pass test, jenkins would not deploy it.
But I prefer fix bugs before deployment
Had a very similar issue.
The thing is - webfear - sorry could not resist ;-) does not initialize everything on startup.
To trigger a controlled request, I added a ScheduledEJB to the startup of the application. This bean itself triggered a http-request to a defined URL, which itself triggered:
any filters to get initialized in the chain
any contexts which are needed are initialized
And this itself ensured that my application (EAR or WAR) got very quickly tested after deployment. This works well with some small amout of requests per minute
If you work with high load, means tons of requests per second, you need to choose a different approach.
In this case I added a polling mechanism into the #Startup of the application, which polled every second or 250ms (depends on the load of the application).
This firing to the server ensured, that my #Startup bean was the very first which triggered the possible init issues in the application. If this happened I initialized a filter which always reported a 500 (or better fitting error) to the requestor.
Of course stop your firing bean, as soon as you get the 500, else your admins may like to kill you. (happend to me, since I produced tons or monitoring issues ;-) )
And of course on the regular operation, after your application started properly, you should also disable the polling
Look for a try-catch in the top level of your application code that is catching the Spring exception and allowing the application to continue running.
If the Spring exceptions being thrown are permitted to propagate to the top of the stack, the JVM will stop and there's no way it can keep running, far as I know.

Annoying Tomcat issue with WAR files

I am having an annoying issue with Apache Tomcat's handling of WAR files.
After deploying a WAR file using Tomcat Web Application Manager, the file becomes locked. I can not delete it, rename it or do anything with it. Stopping the application, undeploying it and even stopping Tomcat does not help - I need to restart Windows.
P.S. I'm running Tomcat 8.5.9 on Windows 7.
P.P.S. My quick internet search reveals a few mentions like "Yeah, right, that happens" - but nothing like a major showstopper that I'm having.
I figured what was going on. Tomcat is off the hook.
What was holding a lock was a web browser (Firefox) where Tomcat Web Application Manager was loaded. As soon as I close the Tomcat tab in my browser, file lock is released.
Interestingly enough, this behavior seem to be specific to Firefox. Chrome was good, while IE 11 could not even properly deploy the war.

Still have Eclipse EE 404 on Mac after following advice on this issue

First of all, I am aware that there are other questions regarding Tomcat, Eclipse, and the infamous 404 error. However, none of them manages to resolve the issue. I have spent well over 24 hours on this issue.
To save time, when I configured everything (including Tomcat, and creating a server in Eclipse), I:
• Changed the server location from "workspace metadata" to its correct location by using the "Switch Location" button located in the server's Properties window.
• I chose the "Use Tomcat Installation" option in Server Locations, and saved the choice I made.
In both cases, I restarted the server. If you're curious as to what app I'm currently working on, it's a simple Hello World app, found at: http://theopentutorials.com/examples/java-ee/servlet/how-to-create-a-servlet-with-eclipse-and-tomcat/
• I have included the Java file in the "welcome file" list inside web.xml.
Lastly, out of curiosity, why does the Eclipse browser only go to the project directory, and not the servlet itself? (If I add on the servlet name, then "Hello World" appears).
• Yes, if I enter "http://localhost:8080", the default Tomcat page appears, so no issues there.
Can anyone clue me in, as to why I am still getting 404s after all this, and following advice that has been marked as "Accepted" here at SO, such as the following:
HTTP Status 404 - The requested resource (/) is not available
Thanks in advance for any help, it is greatly appreciated.
The error 404 may occur because of large amount of different reasons. In order to resolve that, you should check your tomcat log file out first. It contains by the path:
%PATH_TO_WORKSPACE%\.metadata\.plugins\org.eclipse.wst.server.core\tmp%SERVER_NUMBER%\
logs
Usually it contains some stacktraces which discribes the problem. If not, then you should check your deployed application out there:
%PATH_TO_WORKSPACE%\.metadata\.plugins\org.eclipse.wst.server.core\
tmp%SERVER_NUMBER%\___YOUR_APP____
It might happen that your application was not deployed correctly by eclipse plugin (happens very often) and you should try this:
Project --> clean
'Right click on your server' --> clean
Or just remove your webapp from the directory I mentioned erlier and redeploy it from scratch.
There is something basic you need to understand regarding using tomcat(or application server for that matter). There is a slight difference between using from Eclipse and using from outside
Using From within Eclipse
What happens here is that Eclipse (by default) uses a copy of your tomcat installation and places it in its metadata workplace. This secondary tomcat is used by Eclipse for all deployments, re-deployments and all. Keep in mind that this is not your original copy of tomcat installation.
The difference in this tomcat installation is that is actually a minimal server, meaning that although it has all the deployment capabilities, it does not have some of the extra features that come with the tomcat installation and one main feature is the tomcat's homepage (the only reason why people out there get the infamous 404 resource not found when they try to run-on-server their application).
Workaround
Although not an issue (nor a bug from the Apache's end), you can still view your application by changing the URL to your application's url, homepage or no homepage ! All you have to do is change the url from http://localhost:8080 to http://localhost:8080/yourApplicationName and voila , the default page of your application will be shown that you mentioned in the welcome-page-list. Keep note that if you didn't specify a default page in your web.xml, you will again wind up with, yet again, the dreaded 404 resource not found page. The reason is that Tomcat has found your application, but it doesn't know what to do at the root context of your application. You can either map your servlet to the root of the application (that way it will always run at http://localhost:8080/yourApplicationName) or you can change the URL to the url-pattern that you mapped with the servlet in the web.xml, it must be something like http://localhost:8080/myApplicationName/myServletMappingPattern

Avoid Server restart after publishing resource in eclipse?

i am using eclipse server to the publish my web application to my local tomcat server.Whenever i modify
java or non java resource, it gets published to server(as i have selected automatically publish when resource change).But problem
is as soon as resource is published, server gets restarted which i want to avoid as it takes ample amount of time. How to avoid server restart ?
I think you are looking for hot deployment?
Heres a good tutorial I seen a while ago http://www.mkyong.com/eclipse/how-to-configure-hot-deploy-in-eclipse/
Whenever you change your code, Automatically eclipse detect your source has modified, and start redeploying your actual code into server. So that Tomcat server is restarting in a particular time interval.
You can configure tomcat for reload automatically, configure the attribute reloadable to true of the Context.
For do Tomcat 7 you must do.
Edit CATALINA_HOME/conf/context.xml
Change:
<Context>
For:
<Context reloadable="true">
Where CATALINA_HOME is your tomcat installation.
clicks on the “Module” view, make sure “Auto Reload” is “Disabled“. Default is enabled. It will stop the auto restart.
To do it in one go for all modules
In server options, uncheck option Modules auto reload by default
Also have a look at Stop Eclipse restarting my web app on file save

Difference in deploy and redeploy

Could anyone please tell me, what the meaning of the word "Deploy" and "Redeploy" in context of Tomcat in the following line:
ServletConfig parameters won't change
for as long as this servlet is
deployed an running. To change them,
you'll have to redeploy the servlet
Thanks very much in advance.
When it says "deployed" that means Tomcat read the Servlet definition (usually a web.xml inside a war) and started the Servlet, which is now available for use. This is when ServletConfig parameters are passed to the Servlet.
When it says "redeploy", it means any way you force it to re-read the Servlet definition (which will re-read the ServletConfig parameters).
The easiest way to redeploy a Servlet is to stop Tomcat and start it again. When Tomcat stops, it undeploys everything that was deployed. When Tomcat starts, it deploys everything again.
Restarting the server may be overkill for you if all you want is to have one Servlet re-read its configuration. A faster way (in server time, not necessarily the time it takes you to figure out how to do it) to redeploy a Servlet is called hot deploy. Hot deploying is when you redeploy a Servlet when Tomcat is still running. See the Tomcat documentation for more info on how to do it in Tomcat.
This means that if your server is deployed and running (i.e. working) then your changes will not show up until you redeploy (i.e. stop the server and deploy the code and start again).

Categories

Resources