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. |
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.
|
|
This version of Weblogic SIP Server exhibits two behaviors that do not conform to the JSR 116 specification:
Also, WebLogic SIP Server does not support dialog stateless proxies, an optional feature described in the API JavaDoc for the “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 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.
|
|
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.
|
|
<ACK received in state PROCEEDING:class=[ServerTransaction], objid=[25292416], key=[z9hG4bKc227250e04757a91cbdde388192e21f5], state=[3,PROCEEDING], method=[INVITE]> |
|
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
PeerGoneException s 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 ).
|
|
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.
|
|
Testing on Solaris platforms has shown that the following JVM arguments to improve performance with the Sun JVM for replica servers:
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.
|
|
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:
For more information see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6230761
|