The rock group Aerosmith didn't have computer networks or Web applications in mind when they wrote the hit song "Livin' on the Edge," but the title is very appropriate for applications that need to cache or offload content around the edges of the network in order to put that content closer to the user. Under what circumstances would you want to do this? Consider the simple network diagram in Figure 1 below.

Figure 1.

If the user enters a URL to access dynamic data -- for example, a baseball team's schedule or a local weather forecast -- the stream of processing to handle this request would likely involve all of the pictured entities and associated network hops. Consider even further that inside the application server there are servlet and EJB containers that are to do the same, repetitive work for all user requests even though the exact page results are returned every time in these two sample cases. After all, a baseball team's schedule, typically consisting of over a hundred records, doesn't change much except perhaps for a few rescheduled rained-out games. Similarly, a weather forecast changes only a few times each day. However, the daily page hits that some weather forecast sites, such as weather.com, must endure are very high. These types of pages, although dynamic in the strict sense of the term, are mostly static in nature. Therefore, it makes no sense to stress the network and systems over and over again to return the exact data in these situations. Conversely, you would not want to cache private information, such as a list of previous orders for a customer.

What is dynamic caching?

Caching of static Web resources, such as HTML and graphic files, has been around for some time now, and while still very useful, can be considered somewhat passé as far as technological advances go. How much of any site these days is really static? With the advent of personalized portal-type front pages for many sites, the last vestige of static-ness (good old index.html) is quickly fading. IBM WebSphere® Application Server, Advanced Edition, Version 3.5.3 introduced a new feature called dynamic caching. Essentially, this adds intelligence to the Application Server, so that calls to servlets or JavaServer Pages™ (JSPs) can be analyzed to see if they are designated as cacheable. If it is, a check is done to verify whether this particular request has already been made (such as the weather for Boise, Idaho or the New York Mets's current season schedule) and then, whether that request exists in the Application Server's cache. If it is there, that cache entry is returned immediately, without bothering the backend systems further. I will discuss these processes in more detail later in this article. The request/response traffic now looks like the diagram in Figure 2 below.

Figure 2.

You can see the savings in avoiding network hops to the backend systems/database servers, and not bothering the servlet engine or EJB container to satisfy this request. As a result, our response time is faster and we have reduced the load on physical network devices and servers. The amazing thing is that dynamic caches, such as WebSphere Application Server's, can cache not only by servlet/JSP name or URI, but can also factor in request parameters/attributes and even session variables to determine if this particular request has been made before and exists in cache! I will discuss this more later.

What is an external dynamic caching proxy server?

Maybe you're somewhat of a perfectionist about optimizing things to their utmost. You're not happy with the above scenario because we still have many network hops and have had to bother the application server (a very busy entity!) in order to return data that already exists in static form in the cache. The above may be acceptable in an Intranet scenario, but is still bothersome in an Internet configuration due to the firewall and network traffic. There is a more efficient solution for people like us! A separate external caching proxy server can be configured to sit in front of the Web/HTTP server, at the very edge of the network and closer to your users. You can set up several of these boxes, which can share external caches between themselves. This enables us to cache and return this dynamic data in a fashion similar to the diagram below. IBM has a product called WebSphere Edge Server that provides this capability through Edge Server Caching Proxy component (formerly called Web Traffic Express). Edge Server provides the ability to offload the dynamic caching work as well as the use of critical memory and CPU cycles from the application server. It provides more power in its ability to have a larger, file-based cache than WebSphere Application Server's in-memory cache, and its ability to create cache groups. It puts the data even closer to the user, as shown in Figure 3 below.

Figure 3.

Edge Server has other features as well, such as the Network Dispatcher component which allows IP spraying (load balancing) between Web servers.

Not shown here is the interaction and communication between the external caching proxy server and the application server indicating when pages are valid, if they are in cache, etc. An invalid page in this scenario causes the application server to notify the external caching proxy, which will then invalidate its own copy. When using a separate caching server such as Edge Server, you need to make decisions regarding whether to use a reverse or forward proxy setup. Since there are many tradeoffs to either approach, consult with your network and Web server administration staff, taking into account what percent of your content will be cached as well as other factors, such as the complexity that this brings to your network configuration. With a reverse proxy approach, you use the host name for the proxy server in the URL for the Web application, so that the proxy can intercept the request and make an intelligent decision as to whether to serve up the page from its cache or defer to the actual server that hosts the application. With a forward proxy, the request goes to the Web/application server first, and from there a decision is made as to whether to defer the request to the external caching proxy server. Pictured above is a reverse proxy configuration. The application server must have a dynamic caching interface to interact with the caching proxy server.

How dynamic caching works

Since JSPs are really servlets under the cover, I will refer only to servlets for the balance of this article. However, keep in mind that JSPs as well as native servlets are cacheable.

WebSphere Application Server, Version 3.5.3 builds hooks into the servlet engine to intercept calls to a servlet to first check whether the request can be served from cache before executing it. Servlets can be designated for caching by their class name or by URI. In cases where multiple URI aliases can result in the same servlet being executed, all of those URIs must be designated in the configuration if you are using URIs to designate cacheable servlets.

If the servlet is designated as cacheable (you'll see how to do this later) and the results are in cache and valid, the cache entry is returned without executing the servlet. If the entry is not in cache, or has been invalidated (either through its configuration entries of prioritization and time-out, or programmatically), the servlet is executed and its results are placed in the cache. Suppose we have the URI /servlet/ForecastServlet?city=Boise. If we designate the ForecastServlet for caching and this URI is executed, the forecast results are cached. Would we want that servlet's cache entry to be returned for /servlet/ForecastServlet?city=Miami? No. Such results create a calamity for users! When a cache entry is created for a servlet, you can indicate request parameters and attributes and even session values that are to be taken into consideration when building and returning cache entries. The original forecast request for Boise is cached, and only returned on subsequent requests for that servlet with the value "city" equal to "Boise." Separate cache entries would be created for each city, leading to efficiencies with most-requested values such as Orlando, Florida. These values are all components of the cache identifier. A cache entry ID is created by concatenating the URI, parameter name/value pairs, and other information.

External caching proxy servers, such as WebSphere Edge Server, can define different groups of external caches to be used, each with its own set of member caches. The generated pages are copied to the external cache groups on the caching proxy server, resulting in two parallel entries in WebSphere Application Server dynacache and external caching proxy server. The vendor of the external caching proxy software will typically provide Java™ components to be used by WebSphere Application Server in controlling the external cache. These are designated in the appropriate configuration files (as you will see later) and placed in the Application Server classpath.

Cache invalidation

Varying degrees of granularity can be placed on the cache time-out values for each individually cached item. A very static set of information, such as the baseball team's schedule, could be set for a long time-out value, such as six months. However, a weather forecast may need to be timed out and refreshed on an hourly basis. Let's consider the consequences of a game that is rained out and rescheduled. If our configuration for that entry specifies that the cache does not time out for months, how do we get the schedule page updated in the cache so that our users can see it? With a little code, at the completion of the transaction that updates the schedule, the servlet involved in this activity would simply send a message to the caching system telling it to invalidate that particular page. Upon the next request for the page, the new data is reloaded and cached, resulting in all subsequent users receiving the updated page. Cache entries can be removed under three circumstances.

• One of the cache's invalidation methods has been called directly inside a servlet's code.
• The time-out for that cache entry has expired.
• The cache is full and a new entry must replace an old one, based on the designated priorities.

I will not discuss the first option since the focus of this article is not on programming (an example is provided later in the code for our example application). The second and third are configured later in this article when I discuss the configuration files that control the caching process.

Back to top

Building the application

With the preliminaries out of the way, let's build an application and configure it for dynamic caching with WebSphere Application Server and Edge Server. Remember, our application development and use of tools is strictly a quick path to focus on the core subject matter of this article, and will not incorporate many of the optimizations or recommended best practice techniques that normally go into a production Web application. This article is about dynamic caching features and how to use them, as opposed to programming, so we'll use mostly wizards to get the job done. It assumes that you already have the required tools installed and configured properly, and know the basics of how to use them. If you need help in these areas, use the documentation and Redbooks available on IBM sites specifically for these tools. We will build a baseball schedule application for a fictitious team, the Mudhens.

DB2® Universal Database

If you don't have DB2, you can refer to the database schema in this article to build a similar database in any product for which you have a JDBC driver that is compatible with WebSphere Application Server.

Our first stop will be IBM's DB2 Universal Database, Version 7. After launching the DB2 Control Center, follow these steps to create your database and table.

1. Expand the tree to the Databases tab, and right-click on it. Choose Create...Database Using Wizard from the menu. Specify the database name to be Mudhens on the first pane in the wizard, and then press Finish to create the database.
2. Expand your new Mudhens database folder, and right-click on the Tables folder. Select Create...Table Using Wizard from the menu. In the wizard, enter Schedule as the table name.
3. Press Next to move to the column selection pane. Choose the sample table Events from the column categories list. This table is close enough to what we need, so we will base our Schedule table on it in order to get our database configured quickly. Select the fields EVENT_ID, EVENT_NAME, EVENT_TYPE, EVENT_OWNER, START_DATE, START_TIME, LOCATION, and NOTES. Select these fields into the Columns to Create list.
4. Press the Next button to display the Change Columns pane. Use the Change button for the EVENT_ID field to:
   
   
   • Change its type to BIGINT.
   • Select the Generate Column Contents checkbox.
   • Select the Identity radio button.
   • Set the Increment value to 1.
     
     
5. Press OK to save the changes and return to the Change Columns pane.
6. Press Next to move to the Primary Key pane. Select EVENT_ID as the primary key field.
7. Press Finish to complete the table creation.

WebSphere Application Server

In the WebSphere Application Server, Version 3.5.3 Administrative Console, follow these steps to create a Web application.

1. Initiate the Create a Web Application wizard from the wizard drop-down menu. Enter the Web application name Mudhens, and select the Enable JSP 1.1 radio button (to keep up with the latest standard).
2. Press Next and expand the tree on the following pane until you can select the servlet engine in which you wish to place this webapp (Default Servlet Engine, in my case). Change the Web application Web path to /Mudhens (I find the default /webapp/ prefix to be excessive).
3. Press Next, and accept the default directories for the servlet and Web components of your application (unless you choose to put them somewhere else).
4. Press Finish to create your Web application.
5. Right-click on the Mudhens Web application, and choose Create...Servlet. Enter ScheduleList for the servlet name, Mudhens, and ScheduleList for the servlet class name.
6. Press Add to add a servlet Web path, and enter servlet/Mudhens.ScheduleList after the pre-filled /Mudhens/ Web path.
7. Follow the same procedure to add the ScheduleInsert servlet to the Web application.

WebSphere Studio

If you don't use WebSphere Studio, you can build simple servlets, JSPs, and HTML files that duplicate the functionality of the ones built here using WebSphere Studio's wizards. The source code for these entities generated by Studio is included in the download below.

Start WebSphere Studio Version 3.5, and complete the following to create the application.

1. Invoke the New Project Wizard and enter Mudhens as the project name. Then, press OK.
2. Highlight the Mudhens top-level folder in the Studio project pane, and select Tools => Wizards => SQL Wizard. Enter ScheduleList as the SQL statement name, and press Next.
3. The following pane should be correctly filled in with the database URL for your database (jdbc.db2.mudhens) as well as the user ID and other information. You should only need to supply the database admin password here. Do so, and press Connect. The Tables pane is displayed.
4. Press Filter Schemas, and select the schema that contains your Mudhens database created earlier (Administrator, in my case).
5. On the Tables pane, select the Schedule table into the Selected Tables list, and press Next.
6. On the Columns pane, select all of the columns into the Selected list, and press Next until you arrive on the Order pane. Select START_DATE and then START_TIME into the Selected column and make sure both have the ASCENDING (up) arrow, and press the Finish button.
7. On the Studio main screen, select your new ScheduleList.sql file, and choose Tools => Wizards => Database Wizard. The ScheduleList SQL file should already be selected, so press Next to get to the Markup Languages screen.
8. Make sure that HTML is checked, and ServletModel is selected in the drop-down list for the code style. Press Next to accept the defaults for the Web pages to be generated. Then, again on the input, results, and method pages, and on the Session page, change the bean name to scheduleListDBBean, and press Next.
9. On the Finish pane, press Rename, and then rename the prefix to ScheduleList. Press OK, and then press Finish.
10. Double-click on the scheduleListHTMLResults.jsp file to open it in the WebSphere Studio JSP Editor. Double-click on the small Java scriptlet at the bottom of the page below the results table (it is a small green J enclosed in braces). In the script editing window that opens, change the code by adding a line below the existing line that closes the result set as follows:

    scheduleListDBBean.closeResultSet(); out.println( "Timestamp=" + System.currentTimeMillis());

    
    This extra line will enable us to see whether the cache is really working. If it is not, the time value at the bottom of the page will continually change. Save the page, and close the editor.

Let's repeat the process to create a screen to use for inserting entries into the schedule.

1. From the Tools/Wizards/SQL Wizard menu item, enter ScheduleInsert as the SQL file name, and choose Insert as the SQL statement type. Press Next.
2. Enter your database password on the following screen, and press Connect. Press Next on the Tables pane since the Schedule table should already be selected.
3. Add the following parameters for each column in the value field. Make sure you are adding them using the Add Parameter button and not typing them directly in the field as values!
   
   EVENT_NAME: opponent
   EVENT_TYPE: eventType
   EVENT_OWNER: team
   START_DATE: eventDate
   START_TIME: eventTime
   LOCATION: eventLocation
   NOTES: notes
   
   
4. Press Finish.
5. Select the ScheduleInsert.sql file, and choose Tools => Wizards => Database Wizard. The insert SQL statement should already be selected in the list, so press Next to proceed.
6. Again, make sure HTML and ServletModel are selected on the next pane, and press Next. Press Next on the Web and input pages.
7. On the Results page, select the fields eventDate, eventLocation, eventTime, eventType, notes, opponent, and team. Press Next on this pane as well as the Methods pane.
8. On the Session page, change the bean name to scheduleInsertDBBean, and press Next.
9. On the Finish page, press Rename to change the prefix to ScheduleInsert, and press OK. Then, press Finish.

Now, let's create a main page for our application.

1. Select the Mudhens project folder again, and choose Insert => File. Choose Blank.html from the Create New list, and change the name to index.html in the entry field. Press OK.
2. Double-click on the index.html file to edit it. Change the default text to Mudhens Schedule Site, and then add static text in two lines below with the values Schedule List and Add a Game.
3. Turn each line into a link: Highlight the text, select Insert => Link, select the To URL pane, and browse for the corresponding target (servlet/Mudhens/ScheduleList.class for the schedule list, and ScheduleInsertHTMLInput.html for adding a game).

Now, set up your servlet and HTML publishing targets, and publish the application to WebSphere Application Server in the directories that you specified when you set up the Web application from the WebSphere Application Server Admin Console. Test the application by adding records (I'm sorry - games!) to the Mudhen's schedule to ensure that it is working properly. Keep in mind that the date format default is YYYY-MM-DD and the time format default is hh:mm:ss. You should be able to get to the main page (index.html) with the URL, http://mynode/Mudhens.

Configuring for WebSphere Application Server Dynamic Caching

First, let's set up the application for dynamic caching using WebSphere Application Server's internal facilities that were first provided as a technology preview in Version 3.5.3. The details of this facility and how to use it are in the WebSphere Application Server InfoCenter (make sure you access Version 3.53 or later), which I cannot recommend enough for its breadth and depth of information. We'll work through the basic steps here in order to get dynamic cache working for our simple example, but I do recommend that you read this information to learn how to implement this for more sophisticated applications. In short, there are two XML files that need to be placed in the /WebSphere/AppServer/properties directory (adjust if necessary for your true WebSphere Application Server root install location) and edited. They must conform to their corresponding DTD files in that same directory. These XML files are defined below.

• dynacache.xml
  Turns dynamic caching on/off based on its presence in this directory. It also has parameters to control the size of the cache and to register any external caches to be used, such as IBM Edge Server Dynamic Caching Proxy.
  
  
• servletcache.xml
  This is where you would identify the servlets to be cached. You can specify the following in this file:
  • Servlets that are to be cached by class name (in which all instances of this servlet would be cached), or by URI (be sure to identify all URI aliases which will invoke this servlet!).
  • Time-out values, priorities, and whether each servlet will be served from an external cache.
  • Which parameters, attributes, or session values will be factored into creating the cache entry IDs for each servlet (refer back to our discussion of how this is important in the context of the weather forecast servlet).
  • That a servlet is NOT to be cached, by using the <invalidateonly/> tag, so that control servlets are not cached (which would prevent them from executing).

Important: WebSphere Application Server's dynacache lets users replace the configuration function of the servletcache.xml file with their own custom configuration classes. Programmers can supply classes to handle the functions of generating cache/group IDs, defining metadata such as time-out, priority, and external caching in case any of these values depend on more complex or dynamic variables. This is considered an advanced topic, outside the scope of this article.

Editing dynacache.xml

These two files are already in the properties directory, but given alternate extensions so that they are not active. Begin by copying the dynacache.sample.xml file to a new file named dynacache.xml. Open this new file in a text editor to take a look at it. You will see the settings for the cache size and priority, as well as an area where you can identify an external cache to be used. The cache size is an integer defining the maximum number of entries that the cache will hold. Values are usually in the thousands, with no set minimum/maximum amount. The priority is an integer that defines the default priority for cacheable servlets defined in servletcache.xml. Its recommended value is 1. We begin by using WebSphere Application Server's dynamic caching (dynacache) alone; do not change any of these settings. The presence of the dynacache.xml file that you just created turns on dynamic caching on the next restart of the Application Server, so you can close it without saving.

Editing servletcache.xml

Next, copy the servletcache.sample.xml file to servletcache.xml, and open it in a text editor. Add the following entry just below the sample <servlet> entry for SnoopServlet:

<servlet> 
 
   <timeout seconds="0" /> 
 
   <path uri="/Mudhens/ScheduleListHTMLResults.jsp" /> 
 
</servlet> 

Here, we are designating the response JSP from our schedule list servlet to be cached without any time-out value -- that is, the only way to "uncache" this JSP would be programmatically or by restarting the Application Server. By using a value greater than zero, you can specify the time, in seconds, after creation of an entry that should be removed from the cache. It can also be removed automatically if the cache fills and its priority dictates that it should be flushed.

Running and testing the application

Remember that the only way for the changes to these two files to be recognized is to restart the Application Server. Do so now, and give the application a try. When accessing the schedule listing, you should see the timestamp freeze after the first run. This indicates that the page is being served from cache as opposed to running the servlet and accompanying database bean to provide the results.

This is great! We are now able to present the Mudhens's extensive schedule to their thousands of loyal fans in a very speedy and scalable fashion, with no bother to the backend servlet and database engine. Of course, we're in trouble the minute the schedule changes due to rainouts, player strike, etc. Fans don't take kindly to showing up for scheduled games and then not finding a game to watch! What we need is a way to invalidate the cache for this page whenever the schedule is altered. Alter the source code for the ScheduleInsert servlet in its performTask() method by adding the following line just above the line that does the callPage():

ServerCache.cache.invalidateByTemplate( "/Mudhens/ScheduleListHTMLResults.jsp", 
true ); 

You need to add an import statement at the top of this class for com.ibm.servlet.dynacache.* in order to get this to compile. The fastest and easiest way to accomplish this type of modification to a Java source file is to use the built-in interfaces between VisualAge® for Java and WebSphere Studio. You can modify the servlet in VisualAge for Java with all of the accompanying benefits such as automatic compilation, and quickly retrieve the change in Studio and publish the changes to your site using Studio's publishing facilities. This connection between the two tools is beyond the scope of this article, but is easy to set up. Note that this setup is fully covered in the help documentation and in numerous papers on IBM's WebSphere Developer Domain. You should now be able to test the application by doing the following.

1. Display the Mudhens's schedule several times. You should see the timestamp value freeze, indicating that you are receiving the page by dynamic cache and not by invoking the servlet.
2. Go to the page and add a game to change the schedule. This should invalidate the cache.
3. Display the Mudhens's schedule page again to see a new timestamp value. This indicates the cache was invalidated, causing the servlet to be re-invoked to reread the database and build a new schedule page.
4. Redisplay the schedule page to see the timestamp value freeze again. This means the page is being displayed via cache again.

Configuring for External (Edge Server) Dynamic Caching

For a more sophisticated configuration that doesn't bother the Application Server or serves cache from separate, external servers in widely disbursed geographic areas sitting in front of even the Web (HTTP) servers, we will use WebSphere Edge Server. Dynamic caching, which is facilitated by its Edge Server Caching Proxy component, is only one of the features that make Edge Server a great tool for these types of configurations. It also includes the Network Dispatcher component to load-balance traffic among servers.

For now, let's concentrate on modifying our baseball schedule application to use the external caching proxy features of Edge Server. This article assumes that you have Edge Server properly set up and configured. We'll start by first modifying dynacache.xml on WebSphere Application Server. Remember the <externalCacheGroups> tag mentioned earlier?

To modify this tag, open the file, copy this section out of the commented out area, and edit it as follows:

<externalCacheGroups> 
 
   <group id="WTE-EDGE-1" type="shared"> 
 
   <member address="mynode.myco.com" adapterBeanName="com.ibm.wte.WteAdapter"/> 
 
   </group> 
 
</externalCacheGroups> 

Supply the correct node and domain name for your Edge Server machine in the member address. The group ID is the identifier for a group that exists on the external cache machine. Give the group ID any name, but remember to match that name in the config files on the Edge Server machine. You can define different external caches, each of which has its own sets of member caches. You will see this value placed in one of the external cache's config files, as well as the servletcache.xml file below. The member address is the address of the machine that is running Edge Server. The interface between WebSphere Application Server and one of the member caches is an adapter bean, typically written by the vendor of the external cache. The WteAdapter class specified here is supplied with Edge Server and will be placed on WebSphere Application Server's classpath in a later step.

Now, let's modify our servletcache.xml file. Change the <servlet> entry for our schedule list page as follows:

<servlet> 
 
   <timeout seconds="0" /> 
 
   <metadatagenerator class="com.ibm.wte.WteMetaDataGeneratorImpl" /> 
 
   <externalcache id="WTE-EDGE-1" /> 
 
   <path uri="/Mudhens/ScheduleListHTMLResults.jsp" /> 
 
</servlet> 

As with the WteAdapter class, the WteMetaDataGeneratorImpl class is also supplied with Edge Server and must be placed on the WebSphere Application Server classpath. Now that we've completed our changes to the WebSphere Application Server files, find these two class files (they should be in the WTEROOT/classes/com/ibm/wte directory of your Edge Server machine), and place them in the WebSphere/AppServer/properties directory of the WebSphere Application Server machine. Make sure to create the com/IBM/wte directory tree under the properties directory first and put the files there. Restart WebSphere Application Server.

Next, let's move over to the Edge Server machine and focus on changing the proxy config file ibmproxy.conf. First, configure this machine as a reverse proxy, so that any requests go to Edge Server first, and the WebSphere Application Server machine only in case the request is not in cache. Below is an example configuration entry. Change yours accordingly:

#Pass /* /opt/IBMWTE/usr/internet/server_root/pub/* 
 
Pass /pub/* /opt/IBMWTE/usr/Internet/server_root/pub/* 
 
Proxy /Mudhens/* http://mynode.myco.com/Mudhens/*

Now, we need to configure the Edge Server caching proxy to recognize the source of the HTML (our WebSphere Application Server machine). Add the ExternalCacheMangager directive below to the ibmproxy.conf file:

ExternalCacheManager WTE-EDGE-1 6 months 

This is where we tie the external cache manager ID ("WTE_EDGE_1") that we used in WebSphere Application Server to the external caching proxy machine, Edge Server. We also specify a maximum expiration time of six months. The last parameter is the maximum expiration time, which is when the resource is expired if not invalidated. It can be specified in any combination of months, weeks, days, hours, minutes, or seconds.

We now need to enable a directive in the ibmproxy.conf to enable JSP caching. This directive is in the file but is not enabled by default. Search through the file until you find the section with the heading:

# ===== JSP Plug-in =====

and uncomment the line that is appropriate for the host operating system on your Edge Server machine.

Start the Edge Server Caching Proxy Server and begin testing to see whether the page is cached. Make sure to use the domain name for the Edge Server machine in your URL.

Back to top

Conclusion

Through this article, you have learned how to cache dynamic servlet/JSP content using the native dynacache features in WebSphere Application Server, Version 3.53 and how to tap into the more extensive dynamic caching features of WebSphere Edge Server for more power. Since this is an introductory article, it does not tap into many other available capabilities, such as ways to write your own intelligent caching modules and security on cached content. For more information, check out the following.

• WebSphere InfoCenter
• Edge Server documentation
• WebSphere Edge Server: Working with Web Traffic Express and Network Dispatcher, SG24-6172-00

For the complete sample that we built in this article, download the ZIP file below.

Back to top

Acknowledgments

I would like to thank the Edge Server Test team, primarily Billie Switzer, Doug Slade, and Harry Balish for all of their information and help; Kyle Brown and Keys Botzum for their review of my drafts and excellent advice in bringing the article along; and Brian Martin in Development and Greg Megahan, for documentation.

Back to top

Appendix A: Trouble-shooting Tips

If you experience problems, the following information may be useful. Thanks to Harry Balish of the WebSphere Edge Server Test Team for this information.

WTE is not caching JSPs

Possible reasons include the following:

• The ExternalCacheManager directive ID in ibmproxy.conf does not match the externalCacheGroup: group id attribute in the dynacache.xml file on the application server.
  
  
• The servlet is not configured/running on the WebSphere Application Server.
  
  
• The existing directive CacheTimeMargin in ibmproxy is set for a time value GREATER than the time value of the servlet expiration in Dynacache. Default value for CacheTimeMargin is 10 minutes.
  
  
• Problems on WebSphere Application Server. If this is the case, you may not even be able to find the URL.
  
  
• Conflicting time values between servletcache.xml and ibmproxy.config entries. In general:
  CacheTimeMargin < servlet timeout (servletcache.xml) < ExternalCacheManager

WTE is not invalidating cache correctly

Possible reasons include the following:

• The WTE proxy server ID is not included or incorrect in dynacache.xml file on the WebSphere Application Server.
  
  
• The ibmproxy.conf file has a typo for the WebSphere Application Server ID in the ExternalCacheManager ID.
  
  
• The WTE class files are not on the WebSphere Application Server. The WteAdapter.class and WteMetaDataGeneratorImpl.class files, which are included with WTE, need to be copied into the /opt/WebSphere/AppServer/properties/com/IBM/wte directory. Make sure that these are correctly defined/pathed in the xml files of the WebSphere Application Server.

The servletcache.xml file should include the following:

metadatagenerator class="com.ibm.wte.WteMetaDataGeneratorImpl" 

The dynacache.xml should include the following:

adapterBeanName="com.ibm.wte.WteAdapter"    

WTE Logs

To turn on tracing in ibmproxy (running in -vv mode) for JSP troubleshooting use the following:

TraceLog /opt/IBMWTE/usr/Internet/server_root/logs/trace 

The TraceModules used are:

TraceModule icapi 
 
TraceModule http 
 
TraceModule proxycache 

Use the cache log to verify that the JSPs were caching correctly. Use the tracelog to verify that the invalidates from WebSphere Application Server were being received and that the WTE cache was actually removing the cached entries.

WebSphere Application Server Advanced Edition Logs

The following WebSphere Application Server logs can be useful for troubleshooting (they are located on the WebSphere Application Server machine in /opt/WebSphere/AppServer/logs directory):

Application server stderr log

Application servers send error output to this file. The default name for the default server is default_server_stderr.log. It is used to verify that this Application Server started correctly and that the servlets are also running. Also used to verify dynacache sends invalidates to WTE. If WebSphere Application Server had problems reaching a WTE server for invalidates, the following message will appear in this log:

WTE: IOException during POST 
 
java.io.FileNotFoundException: / 
http://stlab109.transarc.ibm.com:80/WES_External_Adapter  

If WebSphere Application Server log contains WTE server name in exception, check to make sure WTE proxy server is up and running.

Application server stdout log

Application servers send standard output messages to this file. The default name for default server is default_server_stdout.log. It is used to verify that the servlets are started and running properly. This log will also contain entries when the dynacache issues invalidates for the URIs. An example of the valid entries are:

WTE invalidating /webapp/dynacache_test/servlets/cTimeStamp 
 
WTE invalidating /webapp/dynacache_test/servlets/TimeServlet 
 
WTE invalidating /webapp/dynacache_test/servlets/cTimeStamp 
 
WTE invalidating /webapp/dynacache_test/servlets/TimeServlet 
 
WTE invalidating /webapp/dynacache_test/servlets/cTimeStamp 
 
WTE invalidating /webapp/dynacache_test/servlets/TimeServlet 
 
WTE invalidating /webapp/dynacache_test/servlets/cTimeStamp 
 
WTE invalidating /webapp/dynacache_test/servlets/TimeServlet

Top of page

Back to top

Download

Name	Size	Download method
sample.zip	17 KB	FTP|HTTP

Information about download methods

About the author

Rate this article

Comments

Back to top

Table of contents

• What is dynamic caching?
• Building the application
• Conclusion
• Acknowledgments
• Appendix A: Trouble-shooting Tips
• Download
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers