WebLogic SIP Server 2.1 Known Issues

n/a

The default timer queue configured for new WebLogic SIP Server instances, sip.timer.Default, contains only 3 threads. This number of threads yields poor performance for most application deployments. BEA recommends increasing the thread count of sip.timer.Default to 15 threads, and then profiling your applications to determine if additional or fewer threads are necessary. To change the thread count:

1) Access the Administration Console for your system.

2) Expand the Servers tab.

3) Right-click the name of the server to configure, and select View Execute Queues.

4) Select the sip.timer.Default queue from the table.

5) Increase the thread count to 15, and click Apply.

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.

CR236491

If you attempt to install WebLogic SIP Server 2.1 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.

CR236688

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.

CR237223

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.

CR239032

The Tcp Connect Timeout Millis attribute is applied only to SIP protocol channels. The timeout setting is ignored for channels configured for the SIPS protocol. See Managing WebLogic SIP Server Network Resources.

CR243700

WebLogic SIP Server does not persist session attributes after a Servlet makes a call to setAttribute(). For example, in the following code sample the call to modifyState() does not persist call state data in the data tier:

  Foo foo = new Foo(..);

appSession.setAttribute("name", foo); // This persists the call state.

  foo.modifyState(); // This change is not persisted.

As a workaround, ensure that Servlet code always modifies the call state before calling setAttribute(), as in:

  Foo foo = new Foo(..);

foo.modifyState();

appSession.setAttribute("name", foo);

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.

CR244502

The Administration Console allowed you to uncheck the Outbound Enabled attribute for a SIP or SIPS network channel, even though SIP and SIPS network channels can always originate outbound connections. In addition, the Console allowed you to select the HTTP Enabled for This Protocol attribute for SIP and SIPS channels even though HTTP and SIP/SIPS are not supported on the same port number. The Console code was modified to make these attributes read-only for SIP and SIPS network channels.

CR245393

The WebLogic Server Administration Console has several problems that can affect the configuration of WebLogic SIP Server:

• CR241785: The Console does not prevent a user from assigning null to attributes that require actual values. For example, when configuring the Digest authentication provider, the Console will persist null to the mandatory DigestRealmName attribute if none is specified, even though the server will fail to start with this configuration. If you experience this problem, you must manually edit the config.xml file to enter the mandatory value for DigestRealmName.
• CR241822: The Console does not prevent a user from configuring multiple identity asserter providers that have the same active token type. Again, such a configuration prevents the server from starting, and you must manually edit config.xml to either remove a provider or assign unique token types to all providers.
• CR241825: When you view the configuration page for the digest identity asserter provider, the Console always shows PLAINTEXT as the configured value in the drop-down menu for the Password Encryption Type attribute. PLAINTEXT is displayed even if you have previously configured the provider with an alternate encryption type, such as REVERSIBLEENCRYPTED or PRECALCULATEDHASH. Note that the Console does persist the actual value that you selected for the Password Encryption Type attribute when you click apply; ignore the displayed value when you return to the configuration page.

CR249459

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.

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.

CR253622

If you define a message-debug element with the level set to "full" and you also specify the -Dwlss.SipEngine debugging option at startup, the server fails to start and displays a NullPointerException. To avoid this problem, either omit the debugging startup option or change the message-debug level element to "basic" and specify a valid format as described in Enabling Access Logging.