129Configuring web class loading

5.4.2 Configuring concurrency

Connectors are designed to handle concurrent connections from multiple browsers.

There are two main attributes that you can configure: maxThreads, and acceptCount

(for the HTTP connector) or backlog (for the AJP connector).

■ maxThreads—The maximum number of processing threads that can run con- currently. Because the server can’t create any more threads, this parameter ulti- mately limits the number of concurrent users. If all threads are being used, it’s up to the individual connector to provide queuing. If left unspecified, the default is 200 threads.

■ acceptCountorbacklog—Defines the length of a queue. When all request pro-

cessing threads are busy, the connector starts queuing the requests. The HTTP

connector uses the acceptCount attribute, and the AJP connector uses the

backlog attribute. If the queue is full, the connector refuses the request. If left unspecified, the default is to queue 10 requests.

If you have a lot of concurrent users, you want to make sure that none of them is keep- ing a connection open for too long so that other requests can be fulfilled. Let’s explore how to configure connection timeouts.

5.4.3 Configuring timeouts

Sometimes, the resource that a client is trying to access doesn’t respond or responds slowly. We don’t want the client to hog a connection thread indefinitely, so the con-

nector provides a connectionTimeout attribute that you use to specify the number of

milliseconds to wait for the requested URL after a connection is made. For the HTTP

connector, the default is 60 seconds (60,000 milliseconds); for the AJP connector, the

default is 0 (infinite).

5.4.4 Configuring a proxy hostname and port

If you’re running behind a proxy server, you can fool your web applications into think-

ing that you aren’t by using the proxyName and proxyPort attributes. These attributes

override the values that are provided to your application when your code calls the

request.getServerName() and request.getServerPort() servlet methods.

Now that we’ve discussed connectors and how to configure them, let’s see what configuring class loading entails.

5.5

Configuring web class loading

In chapter 3 (section 3.2), we gave you a general background on how class loading

works in JBoss AS. Java EE web applications don’t follow the same default class loading

convention that most other archive types do in JBoss AS. Web applications don’t use a

shared class-loader repository but delegate to the regular system class loader by default. The servlet specification recommends that web applications be isolated from one another, and Red Hat abides by this recommendation.

You can configure web applications to use a class-loader repository in the micro-

deployer/META-INF/war-deployers-jboss-beans.xml. The class loading properties are

part of the WarDeployer bean. You can configure three class loading properties:

java2ClassLoadingCompliance, useJBossWebLoader, and filteredPackages.

The java2ClassLoadingCompliance property is set to false by default, telling the

deployer to load classes from within the web application’s WEB-INF/lib and WEB-INF/

classes directories before trying to load them from the parent (system) class loader. The useJBossWebLoader property is also set to false, telling the container to use its

regular class loader rather than a regular JBoss AS class loader that hooks into a class

loader repository.

You may have a case where you want to load most of your libraries from inside of your

application’s WEB-INF/lib and WEB-INF/classes directories first, but you also have a sub-

set of classes that you want to load through the parent (system) class loader first. In this

case, you can leave the java2ClassLoadingCompliance property set to false but specify

specific package names using the filteredPackages property. JBoss AS will attempt to

load classes that match the packages listed under this property by going to the parent

(system) class loader first. This method only works if the useJBossWebLoader option is

false—that is, there’s no class loader repository.

You should now have a good background on how web application class loading

works in JBoss AS. Now let’s talk about valves, another feature of JBoss Web Server.

5.6

Using valves

Sometimes you want to perform certain actions every time a request comes into the server. For example, you may want to log information about the request, or you may

want to check the originating IP address on a request and block it if it’s on a blacklist.

You can program this logging or blacklisting functionality into your application code, but because it’s not specific to your business logic, you might, instead, accomplish it

using a valve, or interceptor.

TIP People using JBoss Web Server often want to know how to enable web-

server–style access logging. Servers like Apache, IIS, and Tomcat stand-

alone are configured to create log files that show information about

requests made to the server. JBoss Web Server has no logging enabled by

default, but it can be enabled by using the AccessLogValve.

JBoss Web Server provides valves that can intercept requests as they come into the

server. Figure 5.11 shows how requests coming from HTTP clients are intercepted by a

valve, the valve logs information about the request to a log file, and then the request continues to the destined web applications.

You can configure valves for individual applications by defining them in the

WEB-INF/context.xml file. You can also define them at the server level as a sub-

element of an engine or a host in JBoss Web Server’s server.xml file, as we discussed

in section 5.2.3. Only the CachedConnectionValve is enabled by default, but others

131