In production box i want to change the web.xml in a J2EE web application but i don't want to restart the server or the application because this can create problem for lot of online users.
Suggest a way so that my web.xml changes should reflect in the web app.
As far as I know, there's no way of getting around restarting the server if you need it to read the new web.xml, because the config file is read when the server starts (ie. think about it being processed only on servlet init()).
If someone can point out how we can hot deploy config file, I would like to know too though.
Just to throw an idea out... You could embed your webserver (like embedded tomcat) and programmaticly restart it based upon some event. However, there will be a period of time where the webserver is down. Maybe create a new embedded tomcat instance using your new web.xml. You can now direct traffic to the new embedded webserver while you shutdown the old one.
I think we can try using annotations that come with servlet 3.0 specifications.
Related
I have 3 application running on Apache server.
When restart server all application get restarted.
Anyone can explain how to restart single application without affecting other applications in linux.
Thanks in advance!
You can't restart Apache for a single website.
Runnin /sbin/service httpd restart for example will restart Apache as whole, there's no way to restart a single application.
When you say Apache Server, you mean Apache Tomcat? In Tomcat, you can go to the manager page. It's usually in localhost:8080/manager/html. On this page you can start, stop, deploy, undeploy, etc. a single web application. See the Tomcat Manager App How To documentation for more details. Then do a tail -f catalina.out, it should say what app has been started/stopped/deployed/etc.
Simple workaround is to touch specific web.xml file using command touch web.xml.
Tomcat reloads application every time when it notices change in web.xml file, here we are not modifying web.xml file but just touching it.
We have a single Tomcat app server and a single front-end web server running Apache and mod_jk. Is it possible for us to add a second front-end web server, that points to the same app server and also runs Apache and mod_jk?
We don't want to do this for reasons of load balancing. Rather, it's for reasons of migration. The new web server will be an entirely different OS and will use a different SSO authentication module. We want to be able to stage and test it, switch a DNS entry to make it live, and decommission the old server.
The current workers.properties file looks like this:
worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.host=10.x.x.x
worker.worker1.port=8009
Can I just duplicate that config onto a second web server?
I have no experience or background whatsoever with any of this, but have been asked to assist with a server migration and am trying my best to help.
I have been reading the documentation for mod_jk and Tomcat. I have found all sorts of documentation on pointing a single mod_jk instance to multiple Tomcat app servers, but nothing describing the opposite of that, which is what I'm trying to accomplish?
Is this possible?
Edit: I should note that we do not have any access to the Tomcat server, as it is managed by a third-party vendor. I'm sure they'd make changes if we asked them, but we don't have the ability to log into it ourselves.
Yes - duplicating will be easiest. Most important** is keeping the worker name the same.
One gotcha is making sure Tomcat has enough connections available to be handled by both web servers. The normal defaults are typically high enough, but if you try to stress test, the tomcat server may need the sum of workers available on the webservers. But if you don't have enough, Tomcat does write a warning to the logs.
** Most important - Ok - Not that important since you are not using sticky sessions. But could be confusing later if you try this experiment with 2 tomcats when switching between web servers.
Yes, of course you can. I have done it several times, even just to change the static files served by Apache (js, images, css) and test the Tomcat application with a different "skin".
Usually when building a high availability system, not only the Tomcat's or any other back-end servers get replicated, the front-end Apache or IIS or whatever is used gets replicated too.
As you said, it should be fine just copying the workers.properties file and the mapping rules in the Apache httpd's *.conf files.
An also, check with tomcat management team that the incoming connections to Tomcat's AJP port are not limited by net rules or firewalls, making just the old Apache able to reach the Tomcat.
Can I just duplicate that config onto a second web server?
Yes sure, since you want to hit the same Tomcat server so you can simply copy your worker.properties from Apache instance 1 to Apache instance 2. If you have only those 4 properties then nothing but if you have some properties like worker.worker1.cachesize=10 or worker.worker1.cache_timeout=600 and you want to play around then change it. But bottom line is that since you want to hit same Tomcat instance so you can simply copy.
Understanding it in non-tomcat way - you can have more than 1 HTTP web server like Apache intercepting all the requests and then forwarding it to same application or web server. However this is not common because common thing is a web server load balancing the requests for back end application servers.
I have been reading the documentation for mod_jk and Tomcat. I have
found all sorts of documentation on pointing a single mod_jk instance
to multiple Tomcat app servers, but nothing describing the opposite of
that, which is what I'm trying to accomplish?
Is this possible?
You couldn't find in any of the reading because what you are trying is a corner case, generally people configure multiple Tomcat workers to serve servlets on behalf of a certain web server in order to achieve load balancing, virtual hosting etc.
You mentioned that you are doing all this in order to test the Apache running on different OS and using different SSO, I am assuming there is no hardware load balancer sitting in front of your web servers (Apache) so how you are gonna hit your new Apache? I think you need to do this explicitly because your current URL will be pointing your first Apache, so in order to hit second/new Apache you need to give your testers/users the URL containing end point (IP:port) of second/new Apache. Even if you are doing all this locally still you need to have your second Apache listening on different port, or may be different IP but that's not common.
I am not sure what I am asking is correct approach or not. So, let me first clarify my requirement.
Till date I was using each app as a root app and was deploying them in separate tomcat instance, but my app number are now growing and I can not keep on deploying a separate instance of tomcat for each app.
There are two things which make me deploy every app as root:
For updating an app you have to shutdown tomcat instance which will also stops other app running in same instance. And I do not want this to happen (as some users are live on one web app or some job is running on some app, so I can not stop all apps at any given time).
For writing urls, if I deploy a web app as root, then in web-app I can simply write "/students/list" , but if I deploy them in same instance with some different context name, then I have to write context name before the urls, like "ctxt1/students/list"
And for developers sake I don't want them to write context name before every url in web-app and also I don't want context names to appear to a user.
Is there any approach with which I can solve these 2 problems. I am thinking of migrating to Glassfish for some apps. If glassfish offer solution to these problems then I can migrate all apps to glassfish as well
Secondly I am running tomcat behind IIS, using ISAPI. If IIS can be of any help here?
You should not use one tomcat per App. The amount of tomcats should increase only when needed (really needed).
It is not true that you have to kill the whole tomcat, for one App update, you should only restart the specific context (going to http://your.tomcat:8080/manager/html).
About the URLs you can use an apache in front with mod_proxy_ajp configured to talk with tomcat (see this: http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html)
I am working at a startup, we are just about to roll out our first beta. Knowing that we will be having a good number of users, we want to have seamlessly deployment when we are adding new features.
I have worked with windows azure before, and I know they support seamless deployment, so I did some googling and cloudbees was the first result.
So the question is, with what we have now (geronimo server, rackspace hosting), is it possible to seamlessly redeploy a java web application? If so, how?
Are there other alternative solution, such as using another hosting provider or use a different web server? (Because it is a startup, it would be beneficial if the answer keeps scalability in mind)
If with a seamless redeploy, you mean an upgrade of your application without any downtime or restarting of your server, LiveRebel might be something to look at.
See http://zeroturnaround.com/liverebel
There are a lot of methods for doing this in the java world. If you don't use sessions (or use shared sessions between app servers) you can do a rolling stop/deploy/start of your appservers, taking 1 offline at a time and using a load balancer to ensure that traffic goes to the other servers.
I have heard Glassfish has such feature, the reference probably ment this (Glassfish 3.x redeploy command) : http://docs.oracle.com/cd/E19798-01/821-1758/6nmnj7q1h/index.html
I have a standalone java application which uses java based TCP NIO to collect some information from various clients (not on web/HTTP but through some indigenously developed middleware). Now I have to develop a front-end for the users to perform a lot of querying through HTTP. So is there a way to put this application inside tomcat, so that servlets can invoke required functions on this application ???
The thing is it has to listen on that middleware outside tomcat too and at the same time service servlets inside tomcat. How to do this ??
Putting this application outside tomcat and using RMI is an option but I don’t want to do that.
Can embedding tomcat inside my application is an option ???
The brand-new Tomcat 7 has Embedded version for download.
Tomcat is big. You should try to embed Jetty, which is meant in order to make it possible.
http://jetty.codehaus.org/jetty/
I don't know about embedding Tomcat, but you can embed a servlet container inside your application using embedded Jetty. If what you want is to add an HTTP interface to an existing server, I think that's the way to go.
It also should be perfectly workable to launch your server's TCP listening components from a standard servlet in Tomcat. Then the servlet can call methods in your existing application directly, while it continues to listen to its usual TCP ports.
A third option is to write a servlet that just talks to your existing server in the same way other clients do.
The way you want to go, is to have an embedded web server to your existing application since you just need a little bit of web functionality.
Going the other way is possible. You can use servlet listeners to get started and stopped, and you need to take great care of any thread you start since Tomcat have no idea they exist.
As Traroth said, embedding Jetty is a much better option than doing the same with Tomcat. You have an example and a small tutorial in the Jetty website:
http://docs.codehaus.org/display/JETTY/Embedding+Jetty
You can always open the ports and listen manually if the requests aren't complicated.
Have you considered going the other way? That is embedding your application inside a web application?
Using spring you can instantiate your web application and then inject in into the appropriate web classes (e.g. struts2 actions).
This way you can deploy your web application into any web server that is preconfigured separate from your application.
If you do have to use Tomcat, you're best just making your application as a .war file which when Tomcat is ran will deploy your code. This can then talk to any RMI/middleware you like.
I'm not sure I understand your comment regarding memory spaces.
At a very basic level you have two choices:
Run your appication and the web
application in the same virtual
machine.
Run your application and
the web application in a different
virtual machine
If you take approach 1, you will be able to get instances of your applications classes from the servlets and call methods on them.
Embed tomcat / jetty inside your application. You will start your application normally through its main method. After starting your app you will need to create instances of the tomcat / jetty classes which will start up their own threads.
Embed your application inside a war file to be deployed on tomcat / jetty. Similar to the previous option instead you will need to start your application from a context listener.
If you prefer approach 2; start tomcat / jetty and deploy your web app and separately deploy your application. You'll now have two jvms running. To communicate between these two processes you'll have to use some form of socket communication: OutputStream/InputStream over sockets; RMI; JMX; JMS etc.