User Tools

Site Tools


opensourcesoftware:tomcat

My Configuration

Tomcat Specific

Out Of Memory Error

When you later run XWiki in Tomcat you may get an Out Of Memory error, especially if you're trying to import large files into your wiki. To solve this allocate more memory to the JVM. For Tomcat this can be done by setting the JAVA_OPTS environment property (on Windows to allocate 300MB you would set JAVA_OPTS to -Xmx300m). If you are running Tomcat as service then defining JAVA_OPTS will not help. There is a utility provided in the bin folder of your Tomcat installation (for example for Tomcat 5.x on Windows it's called tomcat5w.exe). It's a GUI tool which can be used to set various options including the heap size.

http://bugs.sakaiproject.org/confluence/display/DOC/Section+-+Tomcat+Installation+(2.5)


    -Xmx768m
    -Xms768m
    -XX:PermSize=128m
    -XX:MaxPermSize=256m

c:\Program Files\Java\jre6\bin\client\Xusage.txt Server Info

    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:
                      append to end of bootstrap class path
    -Xbootclasspath/p:
                      prepend in front of bootstrap class path
    -Xnoclassgc       disable class garbage collection
    -Xincgc           enable incremental garbage collection
    -Xloggc:    log GC status to a file with time stamps
    -Xbatch           disable background compilation
    -Xms        set initial Java heap size
    -Xmx        set maximum Java heap size
    -Xss        set java thread stack size
    -Xprof            output cpu profiling data
    -Xfuture          enable strictest checks, anticipating future default
    -Xrs              reduce use of OS signals by Java/VM (see documentation)
    -Xcheck:jni       perform additional checks for JNI functions
    -Xshare:off	      do not attempt to use shared class data
    -Xshare:auto      use shared class data if possible (default)
    -Xshare:on	      require using shared class data, otherwise fail.

  The -X options are non-standard and subject to change without notice.

IIS connector to Tomcat

Steps

my specifics

Java JDK path : C:\Program Files\Java\jre1.6.0_07 
Tomcat path : E:\Xwiki\Tomcat 6.0
JSP/Servlet webroot (via IIS/mod_jk) : E:\Xwiki\Tomcat 6.0\webapps 
JSP/Servlet webroot (via native Tomcat server, port 8080) : E:\Xwiki\Tomcat 6.0\webapps
Access JSP/Servlet pages via IIS/mod_jk : http://localhost/[jkmount-mapped url of your webapp] 
Access native Tomcat server : http://localhost:8080/ 

1. isapi_redirect.dll

isapi_redirect.dll is placed in E:\Xwiki\Tomcat 6.0\bin\win32\i386\isapi_redirect.dll

2. New Registry Keys

When IIS calls isapi_redirect.dll, it checks for a local config file in the same directory as the dll. If the config file isn't there, it checks the registry (the registry is the normal way to configure it).

If you wish to increase the logging in the isapi.log file, set it to 'debug' instead of 'info'.

Under "HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0" create the following:
Add Name Value
string value extension_uri /jakarta/isapi_redirect.dll
string value log_file E:\Xwiki\Tomcat 6.0\logs\isapi.log
string value log_level info (can be debug, info, error or emerg)
string value worker_file E:\Xwiki\Tomcat 6.0\conf\workers.properties
string value worker_mount_file E:\Xwiki\Tomcat 6.0\conf\uriworkermap.properties

3. New IIS virtual directory

A virtual directory is needed within IIS to the isapi_redirect.dll file. The based on the registry entry “extension_uri” the dll will be accessed by Tomcat or IIS as “http:/jakarta/isapi_redirect.dll”; therefore, the virtual directory references “E:\Xwiki\Tomcat 6.0\bin\win32\i386”. (iis log file SYSTEM32/LogFiles/W3SVC1 )

  • Using the IIS management console, add a new virtual directory to your IIS web site.
  • The name of the virtual directory must be jakarta (see: entension_uri).
  • Its physical path should be the directory where you placed isapi_redirect.dll (E:\Xwiki\Tomcat 6.0\bin\win32\i386).
  • Give this new virtual directory “execute” access.

4. New IIS ISAPI filter

  • Using the IIS management console, add isapi_redirect.dll as a filter in your IIS web site.
    • To create the website“

 
1. Right-Click on the Web Sites Folder and Select New -> Web Site
2. Click Next and enter "Academus" for a Description.
3. For the IP and Port settings, the default port 80 should be used. If you would like IIS to listen on a
specific interface you may select it here.
4. Click Next and select the path to the root of the web server:
INSTALL_ROOT\unicon\Academus\portal-tomcat-a\webapps
5. Click Next and select only the Read option.
6. Click Finish.
7. Right Click on the Academus Web Site and select properties.
8. On the Web Site Tab, change the Active Log Format to NCSA Common Log Format
9. On the Homepage Tab, select "A redirection to a URL" and Type in "http://SERVERNAME/portal" in
the "Redirect to:" entry box
10. Place a check mark next to the "A Directory below URL entered"
11. On the Documents Tab, remove all of the content page types and add index.html
12. Click apply, but do not close this dialog as we will need it in the next section

  • Under the website properties, go to the ISAPI Filters tab and add a new filter called 'Jakarta-Tomcat' (I don not think the name references anything).
  • The name of the filter should reflect its task (I use the name tomcat), its executable must be E:\Xwiki\Tomcat 6.0\bin\win32\i386\isapi_redirect.dll.
  • The filter should go to:
    • E:\Xwiki\Tomcat 6.0\bin\win32\i386\isapi_redirect.dll

 
4.8 Add .properties mime type
3. In the IIS Manager, right-click on the local computer and select properties
4. Click the MIME Types... button
5. Click New and enter .properties in the Extension field and text/plain in the MIME type field
6. Click OK until you are back to the IIS Manager

5. Jakarta Isapi Redirector to the Web Service Extensions

If you're using IIS 6.0 you must also do the following:

Using the IIS management console, add the Jakarta Isapi Redirector to the Web Service Extensions.

  • Right-click on Web Service Extensions and choose Add a new Web Service Extension.
  • Enter tomcat for the Extension Name.
  • Add the E:\Xwiki\Tomcat 6.0\bin\win32\i386\isapi_redirect.dll to the required files.
  • Check the Set extension status to Allowed.
  • Click on OK.

6. Restart IIS

  • Restart IIS (stop + start the IIS service)
  • make sure that the tomcat filter is marked with a green up-pointing arrow.

7. Tomcat configuration

I changed or created three configuration files. All of them were in E:\Xwiki\Tomcat 6.0\conf.

server.xml

Unchanged

Example: server.xml is the main setup file for Tomcat that specifies virtual hosts, connectors and the like. I added a line to the standard Laszlo setup for the connector on port 8009. Please see the example file below. The original connector for port 8080 I left intact.

<Server port="8005" shutdown="SHUTDOWN">
  <Service name="LPS">
    <Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
  <Connector port="8080" />
    <Engine name="LPS" defaultHost="localhost">
      <Logger className="org.apache.catalina.logger.FileLogger" />
      <Host name="localhost" appBase="webapps" />
    </Engine>
  </Service>
</Server>

An example

/etc/tomcat/server.xml
This is the main configuration file for Tomcat.
Most of it should be set correctly and can be left alone. Please note the section:
  <Connector className="org.apache.tomcat.service.PoolTcpConnector"> 
     <Parameter name="handler" 
       value="org.apache.tomcat.service.http.HttpConnectionHandler"/> 
     <Parameter name="port" 
      value="8081"/> 
  </Connector> 
This configures Tomcat to be an HTTP server on port 8081.
You probably do not want this in a production environment,
it is a security risk, so comment it out once you have set everything up. Comments are done like in HTML, with <!- ... ->.
Near the bottom of the file is the Context section. Here is where you add new web applications.
  <Context path="/examples" 
     docBase="webapps/examples" 
     crossContext="false" 
     debug="0" 
     reloadable="true" > 
  </Context> 
The path defines the URL path that this context is for.
In this example, that would be http://localhost/examples/. docBase specifies where the web application is to be found. You may specify absolute paths,
but if you put a relative path it will be relative to TOMCAT_HOME which is /usr/share/tomcat in Debian, by default. crossContext allows the web app to access other contexts, default is true.
Default for debug is 0. reloadable=''true'' will cause the web application to be recompiled each time it is accessed, which may be bad for a production environment; default is ``true'' however.
When you add a Context to this file, you must update the tomcat.conf that you copied from tomcat-auto, if you decided to copy it.
When you do Virtual Hosts (see Section [*]), you must add the information that would normally go in tomcat-auto to the correct <VirtualHost> section instead.

workers.properties file

http://www.ccl.net/cca/software/UNIX/apache/solaris-t3.2b5/files/workers.properties.txt.shtml

http://www.ccl.net/cca/software/UNIX/apache/solaris-t3.2b5/files/workers.properties-12.shtml

The workers.properties file I created in E:\Xwiki\Tomcat 6.0\conf The workers file tells Tomcat about connectors or 'workers', which port, host and protocol they are using.

This is my configuration.

workers.tomcat_home=E:\Xwiki\Tomcat 6.0
workers.java_home=C:\Program Files\Java\jre1.6.0_07
# You should configure your environment slash... ps=\ on NT and / on UNIX
ps=\
# Define worker
worker.list=wikiWorker
# Set properties for worker 'wikiWorker' (ajp13)
worker.wikiWorker.port=8009
worker.wikiWorker.host=localhost
worker.wikiWorker.type=ajp13
worker.wikiWorker.cachesize=10
worker.wikiWorker.cache_timeout=600
worker.wikiWorker.socket_keepalive=1
worker.wikiWorker.recycle_timeout=300

This is an example.

# Define worker 'example'
worker.list=example
 
# Set properties for worker 'example' (ajp13)
worker.example.type=ajp13
worker.example.host=localhost
worker.example.port=8009
 
worker.example.cachesize=10
worker.example.cache_timeout=600
worker.example.socket_keepalive=1
worker.example.recycle_timeout=300

Another example

/etc/apache/mod_jk/workers.properties
A worker is basically a Tomcat listener, it waits for information from Apache and gives it to Tomcat.
This file comes with all the ``inprocess'' workers uncommented, 
the ``inprocess'' standing for ``in the Apache process'' which is not what we want to do.
Here is my workers.properties (note that the file comes with extensive comments):
  workers.tomcat_home=/usr/share/tomcat 
  workers.java_home=/usr/lib/jdk1.1/ 
  ps=/ 
  worker.list=ajp12,ajp13 
  worker.ajp12.port=8007 
  worker.ajp12.host=localhost 
  worker.ajp12.type=ajp12 
  worker.ajp12.lbfactor=1 
  worker.ajp13.port=8009 
  worker.ajp13.host=localhost 
  worker.ajp13.type=ajp13 
  worker.ajp13.lbfactor=1 
  worker.loadbalancer.type=lb 
  worker.loadbalancer.balanced_workers=ajp12,ajp13 
  worker.inprocess.class_path=$(workers.tomcat_home)$(ps)classes 

Correlation between uriworkermap and worker

Example uriworkermap.properties:

/examples/*=worker1
/axis/*=axis

Example workers.properties:

worker.list=worker1,axis

worker.worker1.host=192.168.1.23
worker.worker1.port=8009
worker.worker1.type=ajp13
worker.axis.host=192.168.1.11
worker.axis.port=8009
worker.axis.type=ajp13 

uriworkermap.properties file

http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html

The uriworkermap.properties is a simple text file that determines the kind of requests that get passed on to Tomcat rather than being handled by IIS.

I created the uriworkermap.properties file in E:\Xwiki\Tomcat 6.0\conf

/xwiki/*=wikiWorker

This is Laszlo's example setup of the uriworkermap.properties file. I set it to handle everything with the url /lps-4.0.2, specifying * rather than *.lzx because I didn't want to have to add a line for every single file extension in Laszlo's directory.

/lps-4.0.2/*=defWorker
/lps-4.0.2/servlet/*=defWorker

If you wanted just .lzx files handled for instance you could just specify:

/lps-4.0.2/*.lzx=defWorker
/lps-4.0.2/servlet/*=defWorker

In summary:

From OpenLaszlo

From OpenLaszlo

Contents

[hide]

Configuring Laszlo to run through IIS using mod_jk/isapi_redirect.dll

Summary for techies

This article describes how to setup Laszlo on Apache Tomcat to work through IIS, using mod_jk to talk between them. It involves downloading the isapi_redirect.dll from Apache's site, configuring IIS to use the .dll and creating or editing some Tomcat configuration files. It may or may not involve a restart of the IIS service depending on your environment.

Other than the normal setup of mod_jk/isapi_redirect.dll described in the below Apache links, you need to add a connector to your server.xml file for AJP, on the same port as the worker you describe in your workers.properties file.

Introduction

Many Windows-based organisations will have IIS running their ASP/PHP website beautifully, but would also like to incorporate Laszlo technology into their website. The easiest solution is to compile a Laszlo application into a Flash file or DHTML package, then place it in your IIS web tree. That's called 'solo' mode and whilst being the easiest to deploy has some limitations compared with 'proxied' mode where you run the scripts directly from the Laszlo server.

The issue with proxied mode is that IIS can't process Laszlo scripts directly, Laszlo is Java based and needs to run in a Java server such as Tomcat or JBoss. However there is a connector 'mod_jk' from the Apache Foundation, which can bridge the gap between Tomcat and IIS. This article is about setting up that bridge, so that when IIS sees a request for an .lzx file, it passes the request to Tomcat and returns the result to the browser.

An advantage of going through IIS or Apache is that if you have a scripting language such as PHP that uses sessions authentication, your Laszlo scripts can use the same session. This means you know who the person is using the Laszlo script and can customise it to them. For example it has been used to limit options available depending on the user's security level.

To start off with, Tomcat is a Java server called a servlet container. It takes http requests just like IIS and the Apache HTTPD server, does some processing and gives a response. It can be a webserver on its own for Java Server Pages (JSP) or coupled with another webserver like IIS or Apache.

Though not addressed in this article it is possible to configure Tomcat for load balancing on various machines. Laszlo doesn't necessarily have to be installed on the same machine as IIS for this concept to work, as long as your isapi_redirect.dll is available to the IIS machine. If you were going to attempt that setup, at a guess you would change the host from 'localhost' to something else in your worker.properties file and update the registry settings.

Most of this information came from these very helpful and better written links:

This link may also be helpful:

What you need

The isapi_redirect.dll connector allows a request from a webserver like IIS or Apache to be made to Tomcat, then the response returned to the browser. Processing of the entire file is passed to Tomcat and the result sent straight to the browser, so this isn't really for processing part of a PHP script, then processing a bit of Laszlo then going back again to PHP.

Tested Environments

The system tested was running Windows XP Professional SP2 with IIS 5.1, OpenLaszlo 3.3.3 / 4.0.0 / 4.0.2 / 4.0.12 bundled with Tomcat 5.0.24. The basic principles should apply to IIS6 on Windows Server 2003 and also using the .war version of Laszlo.

New Registry Keys

When IIS calls isapi_redirect.dll, it checks for a local config file in the same directory as the dll. If the config file isn't there, it checks the registry (the registry is the normal way to configure it).

Please see Apache's mod_jk-IIS setup page for an explanation of the registry settings.
If you wish to increase the logging in the jk_iis.log file, set it to 'debug' instead of 'info'.

Under "HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0" create the following keys:

Name Value
extension_uri /tomcat/isapi_redirect.dll
log_file C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf\jk_iis.log
log_level info
worker_file C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf\workers.properties
worker_mount_file C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf\uriworkermap.properties

New IIS virtual directory

A virtual directory is needed within IIS to the isapi_redirect.dll file. Although it can probably be called something else, I called it 'tomcat' and had it referring to C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf

New IIS ISAPI filter

Under the website properties, go to the ISAPI Filters tab and add a new filter called 'tomcat'.
The filter should go to:
C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf\isapi_redirect.dll

Tomcat configuration

I changed or created three configuration files. All of them were in C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf. Please see below for the changes to each file.

server.xml

server.xml is the main setup file for Tomcat that specifies virtual hosts, connectors and the like. I added a line to the standard Laszlo setup for the connector on port 8009. Please see the example file below. The original connector for port 8080 I left intact.


  
    
	
    
      
      
    
  

In summary:

workers.properties file

The workers.properties file I created in C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf
The workers file tells Tomcat about connectors or 'workers', which port, host and protocol they are working on (not sure how to explain this, maybe a Tomcat expert could explain better).
worker.list=defWorker
worker.defWorker.port=8009
worker.defWorker.host=localhost
worker.defWorker.type=ajp13

uriworkermap.properties file

I created the uriworkermap.properties file in C:\Program Files\OpenLaszlo Server 4.0.2\Server\tomcat-5.0.24\conf

The uriworkermap.properties is a simple text file that determines the kind of requests that get passed on to Tomcat rather than being handled by IIS. This is my example setup of the uriworkermap.properties file. I set it to handle everything with the url /lps-4.0.2, specifying * rather than *.lzx because I didn't want to have to add a line for every single file extension in Laszlo's directory.

/lps-4.0.2/*=defWorker
/lps-4.0.2/servlet/*=defWorker

If you wanted just .lzx files handled for instance you could just specify:
/lps-4.0.2/*.lzx=defWorker
/lps-4.0.2/servlet/*=defWorker

Where you put your Laszlo code

Laszlo code should stay in the normal Laszlo area, for me it is C:\Program Files\OpenLaszlo Server 4.0.2\Server\lps-4.0.2

So a call to a sample page might be http://localhost/lps-4.0.2/my-apps/test_app/bin/testapp.lzx
But it could also be simply http://localhost/lps-4.0.2/test.lzx if you have a single file in the root directory.

It might be possible to store Laszlo files within the main webroot, modifying the uri properties file. That isn't tested though.

Upgrading versions

If you wish to upgrade your version of Laszlo and have already done the above described setup, it is still fairly easy.

Whilst the existing Laszlo is still running

  • install the new version of Laszlo alongside
  • copy the configuration files in the tomcat conf directory, except for server.xml - I'd recommend manually changing it again as it may have a different format.
    • you can test the new setup on a different port by changing server.xml
  • update the new configuration files to the new paths

Whilst the existing Laszlo is stopped

  • update your virtual directory in IIS
  • update your registry settings
  • restart the IIS service if necessary

Troubleshooting and Ongoing Debugging

For development and troubleshooting I run Tomcat off the commandline in a window, rather than as a service. The jk_iis.log log file still tells you more than the window though. IIS by default won't give you enough information in its logs so you'll need to ramp up what it tells you.

You can increase the logging in the jk_iis.log file by changing 'info' to 'debug' for the log level. You will need to restart the service to enact the change.

Increasing IIS logging

These steps are for increasing the level of IIS logging so that you can see GET/POST request details coming from Laszlo. Obviously this is for a development machine rather than a live server and a normal ISP won't be making these changes for you.

  1. as an admin open the IIS console
  2. open the properties of the website where Laszlo runs
  3. enable logging if not already enabled
  4. set it to use W3C Extended Log File Format
  5. click on the 'Properties' button in the logging area
    1. note where it saves the log file for your reference
    2. go to the extended properties tab
    3. enable extended properties and consider enabling Client IP address, URI stem, URI query, Method (this is POST or GET), bytes sent, bytes received, time taken etc.

Checklist

  • Make sure the user IIS runs as has permission to see the Laszlo web tree and to write to the log file (you specify the path in the registry settings mentioned above)
  • Make sure the port for the worker in your properties file and the connector in the server.xml are the same. If they are different or the connector isn't in place in server.xml, you'll see Tomcat make the request but time out with no response
  • Make sure that if you're using sessions authentication, a session is actually active in your browser. Laszlo might be expecting an xml response from the server but instead is actually getting an HTML login page (HTML 4 isn't well-formed so it will generate errors)
  • Paste links or requests in the browser manually to check that you have the right url/uri. Laszlo might be getting a 404 'page not found' or being redirected to a default page (the IIS log will show that too).
  • Make sure the uriworker.properties file is setup to handle the requests - it has to be clear which requests will be handled by IIS and which will be handled by Tomcat.
    • if something is wrong here, you will see IIS display the contents of the .lzx file instead of executing it
  • if your Laszlo page doesn't appear or appears broken in development mode (where it displays compile buttons and the like), remember that the uriworker.properties file either has to have * for all extensions or a line for each extension Tomcat handles eg. *.js *.lzx *.swf *.htm, not just *.lzx, because it uses a page that embeds the Flash. Look in the /lps directory in the Laszlo web tree and see which file extensions are used.
  • Restarting IIS or even the whole machine might help after you set it up for the first time
  • If Tomcat says that it's discarding an unexpected response '100 continue', that message can usually be ignored and the show can go on

opensourcesoftware/tomcat.txt · Last modified: 2009/05/24 16:11 by superwizard