I want to host a tomcat server, which will host 3 web applications. I want to get the total number of requests processed by my server(for any of the 3 web applications). Is there any log from where I can check the total number of requests processed by my server(including HTTP 404 requests)
Note : I can calculate the total requests processed by each individual application and get the total number of requests processed by my server, but the applications deployed in tomcat are third-party and i cant do any changes in it.
Basically, I am building a monitoring application for the tomcat server and I have to provide the total requests served in the application,
Also, My first thought was to over-ride the HTTPServletRequest class constructor in servlet-api.jar and put a static counter. since every request is mapped to HTTPServletRequest object, I guess it will do the job. But is it a good idea to over-ride the HTTPServletRequest or is there any existing solution available for this?
If you do choose to override the HTTPServletRequest class do not just add a static counter, this will cause your counter to reset itself each time the Server goes down/jvm reloads.
I think it might be a better option to either increment it from a database or save the value in a file each time. This way you do not loose your count even if something happens to the server and you have to restart it.
This is all assuming that there isn't already a Apache extension that already dose this and you do want to tinker with the HTTPServletRequest class.
You can use a special filter called Request Dumper Filter for this purpose.
According to official Tomcat Documentation:
The following entries in a web application's web.xml would enable the Request Dumper
filter for all requests for that web application. If the entries were added to
CATALINA_BASE/conf/web.xml, the Request Dumper Filter would be enabled for all web
applications.
Related
Our application accepts incoming requests (REST) and satisfies them using another of our services. When this application boots, it requests a number of connections from that other service - our goal is to maintain a 1:1, thread-to-connection, ratio (I won't get into why, its just that way).
Naturally, we want to define the number of threads/connections in one place, my thought is for the webapp to discover the "maxthreads" value as configured in server.xml -- without having to navigate to and parse the server.xml file. Is this possible?
Thanks
I'll answer my own question - JMX / MBeans.
This link says that earlier versions of Tomcat (before 7.0.54) "renews its threads" thru ThreadPoolExecutor.run().
Why doesn't the init() method of contained Servlets seem to get called again?
A Servlet is initialized only once, either at web application startup or upon first use.
The same instance will then be used to serve all incoming requests, if necessary even multiple requests at the same time (unless you use the deprecated option to synchronize access, but even then there will be just a single instance, and a queue of requests for it).
i am running a tomcat server which has filters (and a servlet) mapped to /xxx/*
I have client that sends //xxx/* at the HTTP header as the uri. as a result, the servlet and the filters are not getting called.
I have tried putting a filter at /* that catches the request, wraps it with a requestWrapper and override the getURI() and getServletPath() methods (they just return the URI with a single / to whoever calls)
That doesn't seem to work, so i am assuming that once tomcat receives a request it decides which servlet/filters should be evaluated against this uri BEFORE even sending it to the first filter.
Is there a way to solve this? can i make tomcat reevaluate after every filter maybe? is there another way?
thanks in advance
If the URLs in the request header are not conforming to the spec, Tomcat is doing the right thing by dropping them.
If this is the problem, you need to fix the client so that it puts proper absolute URLs into the HTTP requests.
"Hacking" Tomcat to make it accept rubbish requests is a bad idea. It will limit your options for upgrading platforms, and/or deploying in different network environments.
My Apache Wicket web application uses JDO for its data persistence in GAE/J.
On application start-up, the home page enqueues a task before it is shown (with zero delay to its default ETA). This task causes the construction of a new Wicket web page, in order to construct the JVM's singleton Persistence Manager Factory (PMF) instance for use by the application during its lifetime.
I have set the application to use concurrent requests by adding
<threadsafe>true</threadsafe>
to the application's appengine-web.xml file.
Despite this, after a single request to visit the application's home page, I get two application instances: one created by the home page visit request, and the other created by the execution of the enqueued task (about 6 to 7 seconds later).
I could try to solve this problem by delaying the execution of the enqueued task (by around 10 seconds, perhaps?), but why should I need to try this when I have enabled concurrent requests? Should the first GAE/J application instance not be able to handle two requests close together without causing a second instance to be brought forth? I presume that I am doing something wrong, but what is it?
I have searched Stack Overflow's set of tags ([google-app-engine] [java]), and the depreciating group "Google App Engine for Java" too, but have found nothing relevant to my question.
I would appreciate any pointers.
If you want the task to use an existing instance, you can set the X-AppEngine-FailFast header, which according to the GAE docs:
This header instructs the Scheduler to immediately fail the request if an existing instance is not available. The Task Queue will retry and back-off until an existing instance becomes available to service the request
It's worth checking out the Managing Your App's Resource Usage document for performance and tuning techniques.
My application consists of 2 servlets,the major one loads the config files in init method and processes get/post requests,
if anything fails during config load, i need to stop the application.
as far i know, i couldnt be able to stop whole application context through some java code ,hence i'm throwing UnavailableException in Servlet.hence i wont be processing get/post request.
but the second servlet does some dynamic reload of configuration on demand.but irrespective of major servlet failed or succeed,it processes reloading requests.
can you suggest a way to check the status of major servlet (running,stopped).so that second servlet can take decision whether to accept reload request or not.
Just share some status variable, like AtomicBoolean between two servlets. By the way, it's more clear design to make both servlets just accept http requests, decode them and pass requests to corresponding business-logic objects. This way, servlets will contain only logic concerned with HTTP sending/receiving.