Tomcat is used for running Java servlets, but it also has the webserver functionality built in, so it can run independently. However, I see several articles on how to integrate Apache Webserver with Tomcat? What's the purpose of doing this? Does it improve performance?
I am using Tomcat for serving WebServices.
Tomcat is a fine Servlet container, but there are a lot of things an Apache httpd can do better (easier and/or faster).
For example Apache can handle security, SSL, provide load balancing, URL rewriting etc.
You can also split content: you can have your Apache httpd to serve static content like images, static html, js etc. and leave the dynamic content (like servlets, jsp etc.) to Tomcat. This also has the advantage that a failure in Tomcat will not render your whole web site unusable / unavailable (just the servlets/jsp pages).
You can also separate the 2 and thus increase security: you can run Apache httpd on one server (which would be reachable on the internet) and direct it to another server running Tomcat, invisible from the outside.
Depends. Quite often a separate web server is used to distribute traffic or allow for extra functionality provided by Apache Web Server modules, which there are plenty. It can also be more performant, depending on your use case.
In short, even if Tomcat has the basic web server functionalities, Apache Web Server can also do other things Tomcat cannot.
Related
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.
We currently use JBoss 5.1 as the application server and my application is mounted on http://<host>:<port>/<myapp>. Images are rendered via the following mount point
http://<host>:<port>/<myapp>/img?id=<image-id>
Currently the servlet rendering image is present as part of the application, but I have re-factored this code to run on a tomcat server.
How should I re-direct all http requests to http://<host>:<port>/<myapp>/img?id=<image-id> a tomcat instance (e.g. http://<tomcat-host>:<tomcat-port>/img?id=<image-id>)
Where should I put this re-direction rule?
Note:Should I introduce a apache http server in front of jboss server to achieve this? Is there a simpler way to configure this in a dev environment?
One way I have seen these kinds of things handled is to host images and other static resources at the ROOT context level on an Apache web server. In this way you can host multiple web applications at various other context levels on the same server and port and they can all benefit from shared static resources.
Another advantage to this approach is that your Apache web server can help offset some load off of your production environment.
I'm building a small web app in Spring so I've been using Tomcat as my application server. The web app requires comet connections so I'm using Tomcat's NIO as the connector. However, another part of the app needs to run a php bulletin board. I've done setups where Apache httpd handles all the requests and passes them to Tomcat using mod_jk only when it needs to. Apache handles all the static and php content.
However, it seems Apache httpd cannot be used like this if Tomcat is using NIO or APR to serve comet requests. Is there a way I can have Tomcat handle all requests and pass php requests to Apache which is hanging behind Tomcat? Or is there some other proxy I can use? Any ideas are appreciated. Thanks!
You could route all of your NIO comet connections through port 8080 and bypass apache altogether and then use port 80 apache for your php.
I use Jetty for comet, which is a really good choice for comet as it is a full web server that can stand on its own, so there is no need for Apache.
Another option is to look into the Querces PHP servlet for Java, which may help eliminate Apache while still allowing you to use php.
I hope one of these options, or a combination of them, helps you solve your problem.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
I've a small doubt in my mind; could anyone please clarify me is the Tomcat web server or Web container?
It's both a web server (supports HTTP protocol) and a web container (supports JSP/Servlet API, also called "servlet container" at times).
As mentioned above, Tomcat is both a web server and a web container, but it's not really meant to function as a high performance web server, nor does it include some features typical of a web server. Tomcat is meant to be used in conjunction with the Apache web server, where Apache manages static pages, caching, redirection, etc. and Tomcat handles the container (web application) functions. You'll often hear the phrase "Apache Tomcat" together, which is both a proper attribution of the Tomcat project (as part of the Apache Foundation), but also appropriate as a label, as they're usually used together as a package.
If you don't have an high performance server requirements and/or want to embed a relatively simple web server with container functionality, Tomcat is fine for that (and probably the easiest embedded web container to work with, comparable with Jetty). Interestingly, the Catalina class used as the main Tomcat engine is actually a subclass of the Embedded class that can be used in a standalone web application.
A web server is any program that accepts incoming HTTP connections.