Table of Contents
This chapter describes basic knowledge of the EJB engine. It also describes the top-level concepts of JEUS EJB, such as its structure, configuration, operation, monitoring, and tuning.
The JEUS EJB engine provides a runtime environment for EJB. The term EJB Container used in the EJB standard is equivalent to the term EJB engine that will be used throughout this manual. For more information about EJB modules and EJB deployment, refer to "제3장 EJB Modules" and "Chapter 4. Common Characteristics of EJB".
The following explains major functions of the EJB engine.
EJB Engine and Managed Server (MS)
A single EJB engine can exist on a MS. However, multiple EJB engines can exist on a single domain because multiple MSs can exist on a domain.
Usually, multiple MSs and EJB engines are configured and executed across multiple machines (CPUs). The MSs are clustered and managed by DAS. Such configuration is often referred to as a cluster of engines. This is desirable since it results in better system performance and higher reliability and safety. In "Chapter 6. EJB Clustering", EJB clustering will be described in detail.
Main EJB Engine Settings
The main configuration file for the EJB engines is <ejb-engine> in domain.xml.
More information will be discussed in "2.4. Configuring the EJB Engine".
EJB Engine Logging
Logs can be written on MSs according to the setting in domain.xml, but a user can also keep a separate EJB engine log (jeus.ejb). Even if a separate EJB engine log is used, the EJB engine log is also recorded in the MS log .
When a file handler is configured in the log handler, the log file is created using the specified file name. It is also possible to display any log messages using a console handler. Normally, in this case, the log messages will be displayed on the command screen, where the MS was started, through the pipe.
A user-generated user handler can also be registered. For more information, refer to JEUS Server Guide. "Chapter 8. Logging".
In active management, the EJB engine sends out email notifications to the administrator if a problem occurs in the EJB modules.
For example, when a fatal error occurs, such as an infinite loop or deadlock due to an error in the Bean class implementation, the EJB engine detects the error and sends out a notification. Additionally,you can configure an error-policy to automatically restart the MS, where the relevant EJB is running, for any abnormal activities.
Detailed active management configurations will be described in "2.4. Configuring the EJB Engine".
When a remote client looks up an EJB instance through the JNDI naming service, it will get back an EJB RMI stub that is used to invoke methods on the EJB. By default, this remote communication from stub to EJB is carried out through the RMI runtime. The RMI communication is based on a TCP socket, which has a constraint in an environment where there is a firewall because it requires a separate TMI communication port. In this case, a special communication mode called HTTP invoke mode is needed.
In this mode, a RMI request from a remote client is wrapped with HTTP and sent to a web engine, which forwards the request to a servlet (jeus.rmi.http.ServletHandler) that handles RMI requests. The servlet sends the request to the RMI runtime, then calls an actual EJB method, and wraps and sends the result to the remote client. The HTTP invoke mode can be configured for each EJB engine or EJB component.
If the HTTP invoke mode is configured in the <invoke-http> element of domain.xml, the mode is applied to all the modules in the EJB engine. The settings in jeus-ejb-dd.xml of the EJB module can only be applied to a specific EJB component. The settings in jeus-ejb-dd.xml takes precedence over those in domain.xml.
For domain.xml and jeus-ejb-dd.xml configurations, refer to "4.2.4. Configuring the HTTP Invocation Environment" .
The following figure shows directories and files used to manage EJB engines.
Basic directories are the same as "1.3.1. EJB Environment and Configuration". Main directories used by an EJB engine are as
follows:
Contains the tool for managing EJB engines.
EJB Engine Management Tool | Description |
---|---|
appcompiler | Creates classes necessary to deploy EJB, compiles and fast deploys the classes |
jeusadmin | Used to control and monitor an EJB engine. |
The directory where the log files of EJB engine are stored. If a separate file handler is specified, a separate file will be created, otherwise, the setting in the server log configuration file will be followed.
This section explains how to configure EJB engines using the WebAdmin.
EJB engine configuration using the WebAdmin is divided into three sections as follows. The specified settings are stored in the domain.xml file, located in the JEUS_HOME/domains/<domain name>/config directory.
Basic
Active Management
Timer Service
A single EJB engine exists in one MS. For adding additional MSs, refer to JEUS Server Guide. "Chapter 2. JEUS Configuration".
The following example configures the basic settings of the EJB engine using the WebAdmin.
Click [Servers] on the left pane to go to the Server List page. Select a server from the list to go to the Server page. Select an EJB Engine to configure the basic settings in [Engine] > [EJB Engine] > [Basic].
Click [Lock & Edit] to change to the edit mode.
Configure the basic EJB engine options and then click [OK].
The following table describes the configuration items of Basic Options and Advanced Options by section.
Basic Options
Option | Description |
---|---|
Enable User Notify | Records EJB exceptions in the user log that is configured on the server. For more information about the user log, refer to JEUS Server Guide. "Chapter 8. Logging". |
The following table describes the asynchronous service invocation options.
This option is used when EJB RMI stubs cannot access an RMI runtime port.
Click [Apply Changes] to dynamically apply the changes.
Active Management setting consists of the engine restart and email notification options. Engine restart condition is determined according to the maximum number of blocked EJB threads allowed before the EJB engine is restarted.
The following example configures the Active Management setting of an EJB engine using the WebAdmin.
Click [Servers] on the left pane to go to the Server List page. Select a server from the list to go to the Server page. Select an EJB Engine to configure its Active Management setting in [Engine] > [EJB Engine] > [Active Management].
Click [Lock & Edit] to change to the edit mode.
Configure the Active Management options and then click [OK].
The following table describes the configuration items of Basic Options and Advanced Options by section.
Basic Options
Configures where to send an email message when the restart conditions trigger an EJB engine to restart.
The following table describes the email notify options.
Click [Apply Changes] to dynamically apply the changes.
The EJB timer service enables you to receive timer callback periodically or at a specified time.
Refer to the EJB specifications for information about basic usage of the timer service. This chapter will cover the explanation and setting of the timer service in JEUS EJB. For more information, refer to "Chapter 10. EJB Timer Service".
System logging and user logging for the EJB engine are configured using the following WebAdmin menus.
System logging and user logging of the EJB engine are configured in the JEUSMain.xml file.
Configuring System Logging
Go to [Servers] > Select a server > [Basic] > [System Logging].
Configuring User Logging
Go to [Servers] > Select a server > [Basic] > [User Logging].
These are common configurations applied not only to the EJB engine but also to all the other engines. Refer to the JEUS Server Guide. "Chapter 8. Logging".
Controlling the EJB engine is identical to controlling any other kind of JEUS engine (e.g., the Servlet and JMS engines).You may use either the console tool or WebAdmin.
Monitoring is essentially gathering runtime data and status information about a particular EJB engine. The following describes how to control and monitor EJB engines using the WebAdmin.
Controlling EJB engines
Click [Servers] on the left pane to go to the Server List page. Select a server from the list to go to the Server page. Select the EJB engine to monitor in [Engine] > [EJB Engine]
Monitoring EJB engines
Click [Runtime View] in WebAdmin. Select an EJB engine to monitor in the same way as for controlling an EJB engine.
1. In order to monitor an EJB engine, it is strongly recommended that you use the WebAdmin tool as it offers much more detailed and complete engine status information than the console tools. For more information about the WebAdmin, refer to the "JEUS WebAdmin Guide"
2. Basic runtime information can be obtained through the console tool. For more information, refer to JEUS Reference Book. "4.2.7. EJB Engine Commands".
There are a number of configuration settings that can be tweaked to increase the overall performance of individual JEUS EJB engines. In this section, we will briefly touch the following performance-related settings of the EJB engine.
The following are required for tuning purposes.
Tuning the resolution setting
Using the fast-deploy feature
Setting up the system log for optimal performance
Not using Active Management
Using the HTTP invoke mode
For more information or tips about the EJBMain.xml file, refer to "11. domain.xml EJB Engine Configuration" section of the JEUS XML Reference. In the XML/Schema, those names marked with 'P' are related to performance.
Resolution checks for the EJB engine status are performed in the following two cycles.
Active management check cycle: Checks the number of blocked threads and then restarts the EJB engine.
Passivation check cycle: Checks all sub components (e.g. Bean pool) and checks whether each Bean should be inactivated.
Use a long resolution period for better performance (by performing engine self-maintenance less often) at the expense of a less reliable engine that wastes system memory. Use a shorter period in order to keep the engine up-to-date but lowering the overall performance.
Since modifying this value may incur significant impact on the system performance, it is very important that you choose an appropriate value.
You should note that the resolution value may cause the <passivation-timeout> or <disconnect-timeout> not to be triggered at the expected time.
Fast deployment option is not configured in the EJBMain.xml file, but for each application, but it has a significant effect on the system performance.
If you know that the EJB modules, that are to be deployed during engine boot-time, have already been compiled to generate the RMI stubs and skeletons, you should use the -fast option. This will cause the engine to skip RMI class generation during the EJB module deployment.
For more information about EJB modules and deployment, refer to "제3장 EJB Modules".
The system log settings can be tweaked in three ways for optimal performance:
If possible, it is better to use a file handler in order to improve logging performance.
Set a large value for the buffer size of the file handler.
Set the log level to SEVERE.
These suggestions only apply to a stable production environment. In the development environment, opposite settings might be preferred, e.g., using console handler, small buffer size, and the FINE log level.
It is not necessary to use Active Management at the EJB engine level. By default, this setting is not used since it could lower the performance. Instead, it is more convenient to use Active Management defined in the Servlet engine. In most cases, Active Management is not configured in the EJBMain.xml file.
Using the HTTP invoke mode can improve the performance when there are high number of requests. Web server controls the number of requests to JEUS by creating fewer connections than RMI, which creates a separate thread for each client request. But keep in mind that converting to HTTP protocol generally lowers the performance.