Release Notes

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

WebLogic SIP Server 3.1 Known Issues

The following table summarizes known issues and problems in WebLogic SIP Server 3.1.

Note: This section describes only those issues associated with the SIP Servlet container and data replication features of WebLogic SIP Server 3.1. See also the WebLogic Server 9.2 Known and Resolved Issues for information about known problems with WebLogic Server 9.2, which provides the underlying OA&M and J2EE capabilities of WebLogic SIP Server 3.1.

Table 3-1 Version 3.1 Known Issues
Change Request Number
Description
n/a
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.
n/a
WebLogic SIP Server MIB objects are read-only. You cannot modify a WebLogic SIP Server configuration using SNMP.
n/a
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.”

n/a
If you attempt to install WebLogic SIP Server 3.0 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.
n/a
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.
n/a
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.
CR303216
During an overload condition, WebLogic SIP Server may log messages similar to:
<ACK received in state PROCEEDING:class=[ServerTransaction], 
objid=[25292416], key=[z9hG4bKc227250e04757a91cbdde388192e21f5], 
state=[3,PROCEEDING], method=[INVITE]>
This occurs even if the ACK could be safely ignored (for example, if the ACK was generated by the server for a 503 response). There is no workaround to this problem, but it should occur only rarely (during overload conditions).
CR314296
WebLogic SIP Server does not support monitoring network channels that use connectionless protocols. For this reason, you cannot monitor UDP traffic using the Monitoring->Channels tab of the Administration Console.
CR267829
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.
CR272491, CR189353
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).
CR294126
When an application in a replicated domain configuration is undeployed, WebLogic SIP Server uses timer processing to clean up the remaining call state data for the application. However, in a non-replicated configuration, the server attempts to invalidate remaining session data but does not destroy call states associated with the application; this may result in the server “leaking” call states that existed during application undeployment.
CR300715
Testing on Solaris platforms has shown that the following JVM arguments to improve performance with the Sun JVM for replica servers:
-server -Xms1024m -Xmx1024m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
For engine tier servers, these example arguments have shown to improve performance:
-server -Xms768m -Xmx768m -XX:+UseParallelGC -XX:MaxGCPauseMillis=400 -XX:+DisableExplicitGC
Note that these JVM settings have only been tested on Solaris platforms. For other platforms, begin with the example JVM arguments described in Tuning JVM Garbage Collection for Production Deployments.
CR302859
In order to use SCTP with IPv4 on Solaris, you must set the -Dsctp.preferIPv4Stack=true Java option when starting the server. You can edit your startup script to include this option, or set the environment variable:
export JAVA_OPTIONS=-Dsctp.preferIPv4Stack=true
CR333737
The main examples index file installed at wlss_home/samples/sipserver/examples/src/index.html includes an extraneous reference to an example named centrex. Note that the documentation on this page is in error. No centrex example is installed with WebLogic SIP Server version 3.1.
CR347957
The Windows XP IPv6 implementation does not support dual mode sockets, and cannot be used with any available JVMs. Using IPv6 with a network channel throws the following exception with either the Sun or JRockit JVMs:
     Address family not supported by protocol family: bind.


  Back to Top       Previous  Next