This section explores the menu options listed in the main category of the server on the Web console GUI.
You can select Server→Information to display system information such as kernel uptime and JVM memory usage. This information is updated in real time as it changes in a graph. This Server Memory Usage portlet uses Ajax (Asynchronus Javascript And XML) technology to perform periodic live updates. Figure 8-2 shows a typical display of system information. Note that not all versions of JDK supports this real-time update, and you may not see a live update display.
Figure 8-2: Real-time system information display
If you click the Server→JVM link, you will see the value to many of the Java system properties for this JVM. This can be quite useful when you are troubleshooting and wondering what the value of a particular system property may be set to.
You can use the Web console to view and search through log files. Server components within Geronimo logs regularly refer to these files. If you click the Server→Server Logs link, you will see three log-related portlets:
Log Manager - For configuring the server settings related to logging on the server
Server Log Viewer - For viewing the general Geronimo server log
Derby Log Viewer - For viewing the logs from the embedded Derby system database
Web Access Log Viewer - For viewing the access log for Tomcat or Jetty, depending on the Geronimo distribution that you are using
Figure 8-3 shows the page of log viewer portlets.
Figure 8-3: Viewing and searching logs with Geronimo Web console
In Figure 8-3, the Log Manager portlet modifies a Log4J configuration file according to your settings. This configuration file is used by the server’s logging code. You can control the attributes shown in Table 8-1.
Attribute | Description |
---|---|
Config File | The configuration file used by the server. By default, this is var/log/server-log4j.properties. There should be little need to change this. |
Refresh Period | Time in seconds between checks made by the server to the configuration file. This is the maximum time that you may have to wait before your setting changes take effect. The default is 60 seconds. |
Log Level | The logging level. The different levels control both the volume of logging information and the type of information logged. The possible values are DEBUG, INFO, WARN, ERROR, FATAL, and TRACE. There are also the values of ALL to print all logs (highly verbose) and OFF to disable logging. |
With the Server Log Viewer portlet, you can search through the entire log (often thousands of lines long) filtering through specific log level, looking for entries containing text that you specify. You can limit the number of lines returned in the result, as well as the range of lines that the viewer will search through.
The Derby Log Viewer portlet shows lines from the system database log file and allows you to filter by line number range and specific matching text.
The Access Log Viewer portlet allows you to search through either the Tomcat or the Jetty access logs (depending on the distribution you are using), capturing the access statistics. You can filter the access entries by date range, by the remote address, authenticated username, the HTTP request method, or the actual request URI.
Selecting Server→Shutdown will show a Server Manager portlet with one single Shutdown button. Clicking this button will shut down the server gracefully. This shutdown is equivalent to pressing Ctrl+C at the system console that is running Geronimo, or running the shutdown batch file in the bin directory.
Figure 8-4 shows the Server Shutdown portlet with the single button.
Figure 8-4: The Server Manager portlet for system shutdown
Selecting Server→Web Server takes you to the Web Server Manager portlet. In this portlet you can:
Enable or disable the Web server statistics display
Configure and control connectors for Tomcat or Jetty
Figure 8-5 shows the Web Server Manager portlet and network connector configuration portlets.
Figure 8-5: Configuration of Web server connectors with Web console
You can start the Web server’s collection of statistics by clicking the Enable link in the Web Server Manager portlet. Figure 8-6 shows the statistics that are collected and displayed by this portlet.
Figure 8-6: The statistics shown by the Web Server Manager portlet
Table 8-2 describes the different types of Web server connectors that you can add to either Jetty or Tomcat.
Connector type | Description |
---|---|
HTTP | Handles regular non-secure HTTP protocol. |
HTTPS | Handles SSL-based secured HTTP connections. |
AJP | Connector for AJP protocol - typically used to connect between the server engine and a front-end Web server (such as the Apache Web server). |
Multiple connectors, listening to different ports, may be configured at the same time with the same Jetty or Tomcat engine. Each connector handles connections using a different communication protocol. Multiple instances of the same connector, listening to different TCP port, may also be configured. Figure 8-7 shows some configuration possibilities.
Figure 8-7: Web Server Network connectors configuration possibilities
In Figure 8-7, the Jetty or Tomcat engine is configured with two HTTP connectors. Users can access the Geronimo-managed applications via HTTP port 8080 or port 8085. A secure connection is available via an HTTPS connector, on port 8443. There is also an AJP connector (on port 8019) that talks to an external Web server - allowing access of the Geronimo-managed application through the Web server.
Note that if you have conflict in these ports when the server is started, it may not be possible to alter their values in the Web console. In this case, you must shut down the server and edit the var/config/config.xml file to resolve the conflict and change their values.
If you click on Server→JMS Server, the portlets here enable you to start/stop, configure, or add both the ActiveMQ message broker (JMS server) instances, as well as ActiveMQ network connectors to the various transports.
ActiveMQ supports a large variety of transport protocols. Each transport protocol that you configure will enable ActiveMQ clients to connect into the server using that protocol.
By default, Geronimo starts one instance of the ActiveMQ message broker as the J2EE container’s JMS server. This instance is named ActiveMQ.
Chapter 16 has more detailed information on working with the ActiveMQ message broker, and configuration of connectors.
Figure 8-8 shows the JMS server configuration portlets on the Web console.
Figure 8-8: Configuring ActiveMQ message broker and connectors with Geronimo Web console
In Figure 8-8, a single instance of the ActiveMQ message broker is running inside Geronimo. This is the default configuration.
In Figure 8-8, two network connectors have been configured. They are vm and tcp connectors, respectively. The vm connector uses fast intra–Java VM communications to speed up connections between Geronimo components and the hosted ActiveMQ message broker, while the tcp connector listen to port 61616 for incoming clients over the TCP/IP network.
Concurrent requests are processed in separate threads to improve system throughput in the Geronimo servers. There are several different pools of threads that are managed by Geronimo.
If you select the Server→Thread Pools menu option, this will display the Thread Pool Configuration portlet. In Geronimo 1.1, this portlet is still a work in progress, and displays the usage of threads in only two of the available pools.
Figure 8-9 shows the Thread Pool Configuration portlet.
Figure 8-9: Thread Pool Configuration portlet and available thread pools
In Figure 8-9, the ConnectorThreadPool and DefaultThreadPool are available for monitoring. If you click the corresponding monitor link, the associated thread usage statistics will be displayed.
The Server→Apache HTTP menu enables you to expose Web applications hosted on Geronimo through an Apache Web server front-end using mod_jk (using the AJP protocol). This menu starts the Apache mod_jk Configuration portlet.
Look back at Figure 8-6 to see a Web Server connected to Geronimo via the AJP connector. The mod_jk module in Apache handles the requests forwarding to the Geronimo server. You must configure this module to point it to the AJP connector listening in Geronimo. This is done through a worker.properties file, plus modification to the httpd.conf file of the Apache server.
This Apache mod_jk Configuration portlet can provide customized instructions for configuration. On some Linux systems, it can even perform editing of the required configuration files for you. Before you start, you must make sure that the application that you want to expose through Apache is already installed and running.
The instructions provide by this portlet are very detailed and are straightforward to follow.
Figure 8-10 shows the Apache mod_jk Configuration portlet’s configuration screen.
Figure 8-10: Use the Apache mod_jk Configuration Portlet to expose the application
In Figure 8-10, the portlet’s Web Application Selection screen is shown. Here, you can select the running Web application that you want exposed through the Apache Web Server. In addition, you can also choose to enable Apache to serve static content from the application.
Note that Geronimo, in both the Tomcat and Jetty distribution, already has the ability to act as a standalone Web server. Configuration of a front-end Apache server is necessary typically for high-volume deployment scenarios.