Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Jetty/Tutorial/Apache"

Line 29: Line 29:
  
 
The [http://httpd.apache.org/docs/2.2/mod/mod_proxy.html mod_proxy] modules are superior in features, maintained with apache httpd, support HTTP and AJP and has a rich load balancer.  We highly recommend using mod_proxy when using Jetty with apache.
 
The [http://httpd.apache.org/docs/2.2/mod/mod_proxy.html mod_proxy] modules are superior in features, maintained with apache httpd, support HTTP and AJP and has a rich load balancer.  We highly recommend using mod_proxy when using Jetty with apache.
 +
 +
=== Configuring Apache ===
 +
Distributions of apache differ greatly about their approach to [http://httpd.apache.org/docs/2.2/configuring.html apache configuration files]. The main difference is if the entire configuration is placed in a single file (apache.conf or httpd.conf) or split up into multiple directories of configuration files (conf.d, ports.conf, mods_available, mods-enabled) with the use of symlinks to activate modules. Configuration may also be done at the server level, or embeded within a VirtualHost configuration of the server.
 +
 +
This tutorial does not recommend or discuss either approach and simply outlines the configuration directives needed. Where these directive are placed will depend greatly on your distribution and existing configuration.
 +
 +
 +
=== Configuring mod_proxy_http ===
 +
 +
 +
 +
=== Configuring mod_proxy_ajp ===
 +
 +
=== Configuring mod_proxy_balancer ===
 +
 +
=== Sticky Sessions ===
 +
 +
 +
 
}}
 
}}

Revision as of 19:35, 15 September 2009



Introduction

Apache httpd is a HTTP server written in C, that is often used to front other web services. Jetty is a full functional and optimized HTTP server and has no need of an apache httpd instance between it and the internet. However, deployers often want to place an instance of apache between Jetty and the internet for some of the following "reasons":

  • Performance. Apache Httpd does have slightly superior performance to jetty for pure HTTP request handling. However, for dynamic response generation, apache must pass the request to another process and the resulting double handling reduces the total throughput to less than direct requests to Jetty. More over, with the advent of comet style web applications, long held requests are common and the apache thread model assigns a thread per outstanding request, so apache does not scale to large numbers of comet connections.
  • Static content. Apache Httpd is very good at serving static content fast. However, Jetty is no slouch either as it can use direct memory mapped buffers for static content, so that only kernel space is used for the data transfer. Besides, if your application has a lot of static content, then you will get much better results by either ensuring good client caching or serving the content from an CDNS edge cache.
  • Security. Some believe that apache gives them a more secure solution as there are no TCP/IP connections terminating on Jetty. However, since Jetty is written in Java, it is not vulnerable to the class of security exploit that a server written in C is. Jetty has a good security record, but has had some past issues, but mostly of the nature that would not have been helped by a fronting instance of Apache.
  • Load Balancing. Apache has several options for load balancing between multiple servlet servers. These solutions are reasonable, but there are better software and appliance load balancers available. The main limitation of apache as a load balancer is that it's threading model is not-asynchronous, so scaling is limited (specially for comet traffic).
  • Administration. Often an enterprise has staff who are very familiar with apache and thus have a strong preference to deploy everything behind apache. This can be a good reason to avoid chaos in a deployment environment, so long as some of the performance and scalability limitations do not affect your web application.

So if we have not yet convinced you to not use apache, read on for the best way to do it.

Details

Which Module ?

Apache provides two mechanisms by which a request that it can receive can be forwarded to a servlet container like Jetty.

Mod_jk is a module written specifically for communicating with the apache tomcat server via the AJP protocol. It includes a load balancer and some management interfaces. Jetty supports this protocol via it's AJP connector, but we do not recommend using mod_jk since:

  • While the binary AJP protocol is more compact than HTTP, there is little benefit from this as the link between apache and the servlet container is often either local or over a fast LAN. Jetty is highly optimized for handling HTTP and HTTP semantics are well known and documented. Using AJP can change those semantics and reduce some key optimizations.
  • The mod_jk modules is maintained with the tomcat project rather than with the httpd project, thus it is not documented to the same standard as other apache modules and there are frequent version issues of which mod_jk should go with which apache.
  • The AJP protocol has been at verion 13 for some time, however there have been changes in the protocol without changing of the version number. Incompatibilities can frequently result.

The mod_proxy modules are superior in features, maintained with apache httpd, support HTTP and AJP and has a rich load balancer. We highly recommend using mod_proxy when using Jetty with apache.

Configuring Apache

Distributions of apache differ greatly about their approach to apache configuration files. The main difference is if the entire configuration is placed in a single file (apache.conf or httpd.conf) or split up into multiple directories of configuration files (conf.d, ports.conf, mods_available, mods-enabled) with the use of symlinks to activate modules. Configuration may also be done at the server level, or embeded within a VirtualHost configuration of the server.

This tutorial does not recommend or discuss either approach and simply outlines the configuration directives needed. Where these directive are placed will depend greatly on your distribution and existing configuration.


Configuring mod_proxy_http

Configuring mod_proxy_ajp

Configuring mod_proxy_balancer

Sticky Sessions

Back to the top