The servlet container hosts all services, including both servlets written directly with the Servlet API and Web services created from WSDL files using the rwsfgen code generator. HydraExpress Web services are implemented as servlets.

Table 5: Servlet container deployment directory structure

3.3.1 Configuring the Global web.xml File

The global web.xml file sets configuration parameters that apply to all contexts. The web.xml file, located in the <installdir>\conf\servlet directory, maps common file extensions to mime-types and sets resources to handle global error pages. Many installations require no changes to the global web.xml file.

The global web.xml file does not define a context, so this file should not define or map servlets, filters, listeners, or named objects. The HydraExpress Agent ignores any such definitions or mappings in the global web.xml file.

3.3.2 Configuring Individual Servlets in the Context-Level web.xml File

Individual servlets are configured in a web.xml configuration file that is part of the project. For Web service projects, rwsfgen generates the file conf\<servicecontextname>_web.xml, which then gets deployed as <installdir>\apps\servlets\<servicecontextname>\WEB-INF\web.xml. The code below shows the web.xml file for the HelloWorld example:

<web-app> <servlet> <servlet-name>GreetingPortService</servlet-name> <servlet-class>rwsf_webservice_servlet .createWebServiceServlet</servlet-class> <init-param> <param-name>configFile</param-name> <param-value>handlers.xml</param-value> </init-param> <init-param> <param-name>serviceName</param-name> <param-value>GreetingPortService</param-value> </init-param> <init-param> <param-name>wsdlFileName</param-name> <param-value>HelloWorld.wsdl</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>GreetingPortService</servlet-name> <url-pattern>/HelloWorld/*</url-pattern> </servlet-mapping> </web-app>

3.3.3 Single-Thread and Multithread Issues

Servlets are inherently multithreaded, so a single instance of a servlet may be invoked from multiple requests threads. However, the servlet container supports a simple mechanism for serializing access to a particular servlet. If a servlet element in the web.xml file contains the attribute single-thread="true", the servlet container only allows one thread at a time to enter the servlet. If a new request arrives for the servlet while a thread is active in the servlet, the new request waits until the active thread leaves the servlet. This slows down the servlet, and may even slow down other servlets in the Agent if many threads are waiting. The container does not prevent threads from entering other instances of the servlet, and other threads in the container remain active when a thread enters a single-thread access servlet.

The servlet element below specifies that only one thread at a time may enter the singleServlet instance.

<servlet single-thread="true"> <servlet-name>singleServlet</servlet-name> <servlet-class>sync.createSingleServlet</servlet-class> ... </servlet>

3.3.3.1 Configuring Multiple Single-Thread Servlet Containers

Although the servlet container is inherently multithreaded, code that is not multithread-safe can be hosted in a servlet container provided that the container is configured so that only one thread is active within servlet code at a given time, as described above. To increase performance, configure more than one connector/handler chain combination, each of which defines a single-thread servlet container, and use a load balancer to balance requests between them. Although this solution provides somewhat lower performance than a multithreaded servlet container, this strategy may provide acceptable performance for single-threaded code in a production environment.