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.
Related
There are following points to make you understand about my application:
I have a traditional spring web application running on Wild-fly.
In my application I have view controller and other controllers.
I have web.xml file and jboss xml file to configure context path.
Request to controller comes through either ajax request or simple get
request from browser.
I want to keep safe my application from possible 'Slow HTTP Post Vulnerability'. For that I have decided if any request takes more than specified amount of time then my application release that connection and throw request time-out exception.
My question is :
How can I implement request time in traditional spring mvc application ?
Note : You are most welcome If you have any other solution to prevent 'slow HTTP post vulnerability'.
You could delegate each controller invocation to a separate thread and then monitor that thread if/until it breaches your timeout condition. Java's ExecutorService already supports something much like this with its awaitTermination() feature.
Using Spring's support for asynchronous controllers (or more generally; implementing non blocking services) would formalise this approach since (a) it would force you to delegate your controller invocations to a separate threadpool and (b) it would encourage you to safely manage the resources available in this threadpool. More details on this approach here and here.
But, however you perform this delegation once you have each controller invocation running in a separate thread (separate from the original invocation, I mean) you will then be able to control how long that thread can run and if it exceeds some configured timeout you can respond with a relevant HTTP status.
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.
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.
I have an applet that communicates with a servlet using Http (Not sockets). Currently, each instance of the applet (i.e. when each applet is run by a different client on a different computer), all the instances communicate with the same servlet. What I want is that each instance of the applet communicate with different instances of the same servlet. Is this possible?
You don't want to have different instances of the same servlet in webapp's lifetime. The normal practice is to use the HttpSession to distinguish between clients. You need to pass the HttpSession#getId() as parameter to the applet in question:
<param name="jsessionid" value="${pageContext.session.id}">
Then, in the Applet connect the Servlet as follows:
String jsessionid = getParameter("jsessionid");
URL servlet = new URL(getCodeBase(), "servleturl;jsessionid=" + jsessionid);
URLConnection connection = servlet.openConnection();
// ...
Here servleturl obviously should match servlet's url-pattern in web.xml. You can alternatively also set a Cookie request header using URLConnection.setRequestProperty().
Finally, in the Servlet, to get and store client specific data, do as follows:
// Store:
request.getSession().setAttribute("data", data);
// Get:
Data data = (Data) request.getSession().getAttribute("data");
Hope this helps.
From your question it seems that your servlet contains state. Every applet will have a session with the servlet container which your servlet can access. You can create an object that holds the state per session and place that object as attribute in the session of the caller. This way the servlet container is free to share one servlet instance among many clients.
The usual way to handle instance-specific actions is to have information stored in the session scope made available by the servlet container, not by having information stored in the servlet itself.
For it to work, your applet must correctly send cookies or the JSESSIONID attribute as provided by the web container or the applet must request a instance specific URL inside the servlet.
I would suggest you familiarize yourself further with the Servlet API specification in order to learn more about what is available to you.
Also note that some application servers support the notion of "clients" which are programs invoked with code served from the application server which have direct access to the inside of the application server code. The actual communication is handled by libraries also provided by the applcation server so this is simple. Glassfish and Trifork can do this.