Configuring and Managing WebLogic SIP Server
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The following sections provide an overview of how to configure and manage WebLogic SIP Server deployments:
WebLogic SIP Server 2.1 is based on the award-winning WebLogic Server 8.1 application server, and many system-level configuration tasks are the same for both products. This manual addresses only those system-level configuration tasks that are unique to WebLogic SIP Server 2.1, such as tasks related to network and security configuration and cluster configuration for the engine and data tiers.
HTTP server configuration and other basic configuration tasks such as server logging, startup, and shutdown, are addressed in the WebLogic Server 8.1 Documentation.
The SIP Servlet container and call data replication features of WebLogic SIP Server are implemented in an Enterprise Application (EAR), named sipserver
, that is deployed on WebLogic Server 8.1. The same sipserver
application code is deployed to both engine and data tier instances of WebLogic SIP Server, but the XML configuration file(s) included in the sipserver
application determine the role of each server instance. A server instance initiates data tier services only if the server name is designated as a data tier server in the datatier.xml
configuration file. Servers that are not part of the data tier provide SIP Servlet container features, and container properties are configured based on entries in the sipserver.xml
configuration file.
The sipserver
EAR is deployed in exploded archive format, and is automatically copied to the top level of the domain directory when you create a domain using the Configuration Wizard (for example, c:\bea\user_projects\domains\mydomain\sipserver
). Figure 2-1, sipserver Web Application Contents, on page 2-3 summarizes the basic structure of the sipserver
application. Only one copy of the deployment files are maintained per domain, and changes to the configuration are made by modifying the configuration files contained in the sipserver
application.
Warning: Never redeploy or undeploy the sipserver
implementation application on a running server. Always use the SIP Servers node in the Administration Console or the WLST utility, as described in Configuring Engine Tier Container Properties
, to make changes to a running WebLogic SIP Server deployment.
Figure 2-1 sipserver Web Application Contents
The config
Web Application in sipserver
provides the logic for parsing the sipserver.xml
and datatier.xml
files and applying configuration changes, as well as the implementation of the Administration Console extensions for configuring SIP features. Because the sipserver.xml
and datatier.xml
configuration files are included within a Web Application, changing the configuration for a WebLogic SIP Server deployment involves modifying these files. Configuration changes to SIP Servlet container properties can be applied dynamically to a running server by using the Administration Console SIP Servers node or from the command line using the WLST utility. Configuration for data tier nodes cannot be changed dynamically, so you must reboot data tier servers in order to change the number of partitions or replicas.
A special MBean included in the SIP Server implementation, ConfigManagerRuntimeMBean
, handles locking and modifying configuration files in response to JMX commands, as well as applying configuration changes to running servers. Therefore, when you edit a WebLogic SIP Server configuration using the Administration Console or using JMX-based utilities, ConfigManagerRuntimeMBean
manages updates to your configuration files transparently. See Configuring Engine Tier Container Properties. If you want to modify a configuration file outside of JMX, you must do so while WebLogic SIP Server is shut down. See Engine Tier Configuration Reference (sipserver.xml)
and Data Tier Configuration Reference (datatier.xml)
.
Note: WebLogic SIP Server start scripts use default values for many JVM parameters that affect performance. For example, JVM garbage collection and heap size parameters may be omitted, or may use values that are acceptable only for evaluation or development purposes. In a production system, you must rigorously profile your applications with different heap size and garbage collection settings in order to realize adequate performance. See Tuning JVM Garbage Collection for Production Deployments for suggestions about maximizing JVM performance in a production domain.
Warning: When you configure a domain with multiple engine and data tier servers, you must accurately synchronize all system clocks to a common time source (to within one or two milliseconds) in order for the SIP protocol stack to function properly. See Configuring NTP for Accurate SIP Timers in Configuring and Managing WebLogic SIP Server for more information.
Because a typical WebLogic SIP Server domain contains numerous engine and data tier servers, with dependencies between the different server types, you should generally follow this sequence when starting up a domain:
startAdminServer.cmd
script installed with the Configuration Wizard, or a custom startup script.You generally start each data tier server by using either the startManagedWebLogic.cmd
script installed with the Configuration Wizard, or a custom startup script. startManagedWebLogic.cmd
requires that you specify the name of the server to startup, as well as the URL of the Administration Server for the domain, as in:
startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001
Following the above startup sequence ensures that all Managed Servers use the latest SIP Servlet container and data tier configuration. This sequence also avoids engine tier error messages that are generated when servers in the data tier are unavailable.
WebLogic SIP Server provides several mechanisms for changing the configuration of the SIP Servlet container:
WebLogic SIP Server provides an Administration Console extension that allows you to modify and monitor SIP Servlet container and data tier configuration properties using a graphical user interface. The Administration Console for WebLogic SIP Server is similar to the console available in WebLogic Server 8.1. All SIP Server configuration and monitoring is available via the SIP Server node in the left pane. See Configuring Engine Tier Container Properties for more information about configuring the SIP Servlet container using the Administration Console.
The WebLogic SIP Server upgrade utility, wlss.UpgradeConfig
, helps you migrate an earlier WebLogic SIP Server configuration to a new WebLogic SIP Server 2.1 configuration. wlss.UpgradeConfig
operates by taking an existing sipserver.xml
configuration file and recreating the earlier configuration using the latest sipserver.xml
schema. For more information about upgrading a configuration, see Upgrading a WebLogic SIP Server 2.0.x Configuration to Version 2.1.
The WebLogic Scripting Tool (WLST) enables you to perform interactive or automated (batch) configuration operations using a command-line interface. WLST is a JMX tool that can view or manipulate the MBeans available in a running WebLogic SIP Server domain. Configuring Engine Tier Container Properties provides instructions for modifying SIP Servlet container properties using WLST.
Most WebLogic SIP Server configuration is performed using either the Administration Console or WLST. The methods described in the following sections may also be used for certain configuration tasks.
You may also edit sipserver.xml
or datatier.xml
by hand, following the respective schemas described in Engine Tier Configuration Reference (sipserver.xml) and Data Tier Configuration Reference (datatier.xml).
If you edit sipserver.xml
by hand, you must manually reboot all servers to apply the configuration changes.
Warning: Never redeploy or undeploy the sipserver
implementation application on a running server. Always use the SIP Servers node in the Administration Console or the WLST utility, as described in Configuring Engine Tier Container Properties
, to make changes to a running WebLogic SIP Server deployment.
Data tier properties, such as the number of call state partitions and replicas, can never be changed while data tier server instances are running. If you edit datatier.xml
, the changes are not applied until the data tier servers are rebooted.
WebLogic SIP Server properties are represented by JMX-compliant MBeans, and access to these MBeans and sipserver.xml
is managed through the special runtime MBean, com.bea.wcp.sip.management.runtime.ConfigManagerRuntimeMBean
. You can therefore program JMX application to configure SIP container properties using WebLogic SIP Server MBeans.
The general procedure for modifying WebLogic SIP Server MBean properties using JMX is described in Configuring Container Properties Using WLST (JMX) (WLST itself is a JMX-based application). For more information about the individual MBeans used to manage SIP container properties, see the WebLogic SIP Server Javadocs.
The Administration Server in a WebLogic SIP Server 2.0.2 installation is required only for configuring, deploying, and monitoring J2EE services and applications; all SIP container configuration is performed using the container's sipserver.xml
configuration file.
Note: If an Administration Server fails due to a hardware, software, or network problem, only management, deployment, and monitoring operations are affected. Managed Servers do not require the Administration Server for continuing operation; J2EE applications and SIP features running on Managed Server instances continue to function even if the Administration Server fails.
BEA recommends the following best practices for configuring Administration Server and Managed Server instances in your WebLogic SIP Server domain:
weblogic.admin.RMI
and weblogic.admin.HTTP
execute queues to match the number of managed servers in your system. Should an Administration Server instance or machine fail, remember that only configuration, deployment, and monitoring features are affected, but Managed Servers continue to operate and process client requests. Potential losses incurred due to an Administration Server failure include:
To resume normal management activities, restart the failed Administration Server instance as soon as possible.
You must increase the default size of the weblogic.admin.RMI
and weblogic.admin.HTTP
execute queues to ensure that an Administration Server can configure and monitor the large number of Managed Server instances deployed in a typical WebLogic SIP Server system. The number of threads in each queue should, match the number of deployed Managed Servers in both the engine and data tier clusters. By default, weblogic.admin.HTTP
contains three threads and weblogic.admin.RMI
contains two threads.
weblogic.admin.RMI
and weblogic.admin.RMI
are internal execute queues and are not displayed for configuration in the Administration Console. To add threads to the default queues, you must manually edit the config.xml
file for your domain to specify the queue configuration. Listing 2-1 highlights the configuration entries required for managing 10 servers (10 threads in each queue). Note that
Listing 2-1 Increasing the Thread Count in Administration Server Execute Queues
<?xml version="1.0" encoding="UTF-8"?>
<Domain ConfigurationVersion="8.1.5.0" Name="my_domain">
<Cluster MulticastAddress="237.0.0.1" Name="BEA_ENGINE_TIER_CLUST"/>
<Cluster MulticastAddress="237.0.0.2" Name="BEA_DATA_TIER_CLUST"/>
<Server ListenAddress="admin_server_address" ListenPort="7001"
Name="my_admin_server" NativeIOEnabled="true"
ReliableDeliveryPolicy="RMDefaultPolicy" ServerVersion="8.1.5.0">
<SSL Enabled="false" HostnameVerificationIgnored="false"
IdentityAndTrustLocations="KeyStores" Name="my_admin_server"/>
<ExecuteQueue Name="weblogic.kernel.Default"/>
<ExecuteQueue Name="sip.tracing.domain" QueueLength="1024"
ThreadCount="1" ThreadsMaximum="1" ThreadsMinimum="1"/>
<ExecuteQueue Name="weblogic.admin.RMI" ThreadCount="10"/>
<ExecuteQueue Name="weblogic.admin.HTTP" ThreadCount="10"/>
</Server>
General administration and maintenance of WebLogic SIP Server requires that you manage both WebLogic Server configuration properties and WebLogic SIP Server container properties. These common configuration tasks are summarized in Table 2-1.
Table 2-1 Common WebLogic SIP Server Configuration Tasks
![]() ![]() |
![]() |
![]() |