n/a

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.

5. Click Apply.

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.

CR244201

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.

CR276062, CR276897

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, you must either:

CR276602

Although the sipserver.xsd schema defines the element, engine-call-state-cache-enabled, this feature is not supported in WebLogic SIP Server 2.2

CR252501

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.

CR273935

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.

CR276039

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:

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:

...
<application>
  <auth-application-id>16777217</auth-application-id>
  <vendor-id>10415</vendor-id>
  <class-name>com.bea.wcp.diameter.sh.WlssShApplication</class-name>
  <param>
    <name>timeout</name>
    <value>1000</value>
  </param>
</application>
...

CR277059

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:

java.lang.AssertionError

at test.ProfileServlet.update(ProfileServlet.java:100)

at

com.bea.wcp.sip.engine.server.CanaryServlet.update(CanaryServlet.java:1013)

at

com.bea.wcp.diameter.sh.Subscription.notifyListener(Subscription.java:116)

at

com.bea.wcp.diameter.sh.WlssShApplication$1.run(WlssShApplication.java:106)

at

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)