Table 2-1 Version 2.2 Known Issues
|
|
|
|
|
By default, new Diameter network channels are created with a default Idle Connection Timeout value of 65 seconds. Change this attribute from the default in order to ensure that connections are not dropped and recreated every 65 seconds. See
Creating Network Channels for the Diameter Protocol in Configuring and Managing WebLogic SIP Server.
|
|
|
WebLogic SIP Server MIB objects are read-only. You cannot modify a WebLogic SIP Server configuration using SNMP.
|
|
|
This version of Weblogic SIP Server exhibits two behaviors that do not conform to the JSR 116 specification:
- MIME content is returned as a String object, rather than as a
javax.mail.Multipart object as encouraged by the specification.
-
isPersistent, used for re-instantiating ServletTimer after server restarts, is not implemented.
Also, WebLogic SIP Server does not support dialog stateless proxies, an optional feature described in the API JavaDoc for the Proxy interface, setStateful() method:
"This proxy parameter is a hint only. Implementations may choose to maintain transaction state regardless of the value of this flag, but if so the application will not be invoked again for this transaction."
|
|
|
If you attempt to install WebLogic SIP Server 2.2 on Fedora Core 3 or 4 with selinux running, the installer throws a java.lang.UnsatisfiedLinkError exception. You cannot install WebLogic SIP Server while selinux is active.
|
|
|
If you configure two or more data tier replicas using the default WebLogic Server Listen Address configuration (which specifies no listen address), multiple data tier instances on the same machine cannot connect to one another. This problem occurs because, using the default Listen Address configuration, JNDI objects in the first booted server bind to all local IP addresses.
To avoid this problem, always enter a valid IP address for each configured data tier server instance.
|
|
|
In a WebLogic SIP Server installation with two engine tier nodes and two data tier nodes in a partition (two replicas), if the connection to the data tier becomes "split" such that each engine tier server can only reach a different data tier node, one of the replicas is forced offline. To recover from this situation, always configure the Node Manager utility to restart data tier replicas automatically when a replica fails. This enables the replica to rejoin its associated partition and update its copy of the call state data without having to manually restart the server.
|
|
|
When using a replicated WebLogic SIP Server installation, the default execute queue configuration for data tier servers poses a risk that garbage collection pauses in engine tier servers will cause delays in servicing other engine tier servers.
To minimize this risk, on each data tier server set the thread count for the weblogic.kernel.Default queue to twice the number of engine tier servers in your deployment. You can set the thread count in the Administration Console by following these instructions:
1. Expand the Servers tab in the left pane.
2. Right-click the name of a data tier server and select View Execute Queues.
3. Click the weblogic.kernel.Default queue in the right pane.
4. Change the Thread Count attribute to equal twice the number of engine tier servers in y our system.
6. Repeat the above instructions for each data tier server.
Increasing the thread count in this manner minimizes the risk that garbage collection pauses in an engine tier server will delay service to other engine tier servers in the data tier.
|
|
|
The Administration Console lists the sipserver implementation application as a standard J2EE application, and allows a Console user to redeploy or even remove the application from a running WebLogic SIP Server installation. The sipserver application must never be undeployed or redeployed except indirectly via the ConfigManagerRuntimeMBean. Redeploying the application yields several nested exceptions starting with InstanceAlreadyExistsException, and forces running data tier server instances to shut down.
To avoid these problems, never redeploy or undeploy the sipserver application using the Administration Console or weblogic.Deployer utility. Perform all engine tier configuration changes using the SIP Servers node in the Console or the WLST command-line utility, as described in
Configuring Engine Tier Container Properties.
|
|
|
In the Administration Console, the Monitoring->General tab displays "Undefined" for the Active Application Session Count and Active SIP Session Count attributes when monitoring a replicated WebLogic SIP Server deployment. There is currently no workaround for this problem.
|
|
|
When starting a replicated domain, if a partition has no running replicas and two replicas are started at the same time, the second replica shuts down if one or more engine tier servers are already running. To avoid this problem, always start all data tier servers before starting any engine tier servers in a replicated domain.
|
|
|
On Linux and UNIX systems, the default TCP connection timeout interval is usually very long and can cause Managed Servers to disconnect from the Administration Server under certain failure conditions.
Specifically, if a single Managed Server in a domain fails abruptly or is disconnected from the network (for example, due to a removed network cable), the Administration Server tries to communicate to the failed server for the length of the TCP connection timeout value. During this time, the Administration Server does not send heartbeat messages to the remaining Managed Servers in the domain. Failing to send the heartbeat messages causes the remaining Managed Servers to consider the Administration Server as being offline, and they disconnect from the Administration Server. This finally causes the Administration Server to throw PeerGoneExceptions for the disconnected servers after the TCP timeout interval has been reached and the connection is closed.
To work around this issue without changing the operating system TCP connection timeout value, use the -Dweblogic.client.SocketConnectTimeoutInSecs startup option when booting the Administration Server. BEA recommends using a value of 60 seconds to avoid numerous missed heartbeats ( -Dweblogic.client.SocketConnectTimeoutInSecs=60).
|
|
|
WebLogic Server 8.5 Service Pack 5 cannot interoperate with OpenSSL when acting as a client. When WebLogic Server initiates a connection, OpenSSL shuts down the connection upon handshake, and no TLS error is generated. There is currently no workaround to this problem.
|
|
|
The Diameter Sh client application included in WebLogic SIP Server 2.2 uses threads from the sip.transport.Default execute queue. Because this queue is also used for general SIP message processing, applications that use the Sh interface may experience poor performance with the default execute queue settings. To work around this problem, increase the number of threads available in the sip.transport.Default queue to a large number (for example, 200 threads).
To change the queue length, perform these steps for each engine tier server:
- Access the Administration Console for your domain.
- Expand the Servers node.
- Right-click the name of an engine tier server, and select View Execute Queues.
- Select
sip.transport.Default in the list of queues in the table.
- Change the Thread Count value to the desired number of threads (for example, 200).
- Click Apply and reboot the server.
The Sh client application may also consume additional threads in sip.transport.Default if the HSS is unavailable. This problem occurs because the Sh application uses a large default timeout value (30 seconds) when waiting for a response from the HSS. Using a smaller timeout value (for example, 1 second) ensures that available threads are not quickly consumed when the HSS is unavailable.
To change the timeout value, edit the diameter.xml configuration file for engine tier servers to configure the timeout parameter. For example:
|
|
|
Although the sipserver.xsd schema defines the element, engine-call-state-cache-enabled, this feature is not supported in WebLogic SIP Server 2.2
|
|
|
Beginning with WebLogic SIP Server 2.2, the "replicated" domain deploys the sipserver implementation application using the default "stage" mode, rather than the "nostage" mode used in previous releases. With stage mode deployment, if you manually edit a configuration file ( sipserver.xml, datatier.xml, or diameter.xml), you must explicitly redeploy the config Web Application component in sipserver to all target server instances. See the instructions under
Default SIP Servlet Configuration.
Stage mode deployment also changes the procedure for applying patches to WebLogic SIP Server. After applying a patch as described in
Applying Patches Using InstallPatch in
Configuring and Managing WebLogic SIP Server, you must either:
- Manually delete the contents of the staging directory for each Managed Server (by default, domain_directory
/server_name/stage) to force a refresh of the deployment files.
- Manually copy the patch file into the
sipserver/APP-INF/container directory in each server's stage directory.
|
|
|
In the profile service API, the SipApplicationSessionAdapter is not recreated after a call state has been restored. This means that if a Servlet on a particular engine creates a profile service subscription and the server subsequently fails, another engine tier server that recreates the necessary call state cannot obtain the session with ProfileSubscription.getApplicationSession(). Attempting to recreate the session throws:
at test.ProfileServlet.update(ProfileServlet.java:100)
com.bea.wcp.sip.engine.server.CanaryServlet.update(CanaryServlet.java:1013)
com.bea.wcp.diameter.sh.Subscription.notifyListener(Subscription.java:116)
com.bea.wcp.diameter.sh.WlssShApplication$1.run(WlssShApplication.java:106)
com.bea.wcp.sip.bea.wls81.connector.WLSTask.execute(WLSTask.java:43)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
|
