Developing SIP Servlets with WebLogic SIP Server

Requirements and Best Practices for WebLogic SIP Server Applications

The following sections requirements and best practices for developing applications for deployment to WebLogic SIP Server:

Overview of Developing and Porting Applications for WebLogic SIP Server 2.1

In a typical production environment, SIP applications are deployed to a cluster of WebLogic SIP Server instances that form the engine tier cluster. A separate cluster of servers in the data tier provides a replicated, in-memory database of the call states for active calls. In order for applications to function reliably in this environment, you must observe the programming practices and conventions described in the sections that follow to ensure that multiple deployed copies of your application perform as expected in the clustered environment.

If you are porting an application from a previous version of WebLogic SIP Server, many of the conventions and restrictions described below may be new to you, because previous WebLogic SIP Server implementations did not support a clustering. As always, thoroughly test and profile your ported applications to discover problems and ensure adequate performance in the new environment.

Avoid Thread Creation

WebLogic SIP Server is a multi-threaded application server that carefully manages resource allocation, concurrency, and thread synchronization for the modules it hosts. To obtain the greatest advantage from the WebLogic SIP Server architecture, construct your application modules according to the SIP Servlet and J2EE API specifications.

In most cases, you should avoid application designs that require creating new threads in server-side modules such as SIP Servlets:

Applications that create their own threads do not scale well. Threads in the JVM are a limited resource that must be allocated thoughtfully. Your applications may break or cause poor WebLogic SIP Server performance when the server load increases. Problems such as deadlocks and thread starvation may not appear until the application is under a heavy load.
Multithreaded modules are complex and difficult to debug. Interactions between application-generated threads and WebLogic Server threads are especially difficult to anticipate and analyze.

In rare situations, creating threads may be appropriate in spite of these warnings. If you must use threads in your application code, create a finite pool of threads so that you can control the number of threads your application creates. Understand where your threads can deadlock and handle the deadlocks when they occur. Review your design carefully to ensure that your threads do not compromise the security system.

To avoid undesirable interactions with WebLogic SIP Server threads, do not let your threads call into WebLogic Server modules. For example, do not use Enterprise JavaBeans or Servlets from threads that you create. Application threads are best used for independent, isolated tasks, such as conversing with an external service or, with proper locking, reading or writing to files. A short-lived thread that accomplishes a single purpose and ends (or returns to the thread pool) is less likely to interfere with other threads.

Avoid creating daemon threads in modules that are packaged in applications deployed on WebLogic Server. When you create a daemon thread in an application module such as a Servlet, you will not be able to redeploy the application because the daemon thread created in the original deployment will remain running.

Test all multithreaded code under increasingly heavy loads, adding clients even to the point of failure. Observe the application performance and WebLogic SIP Server behavior and then add checks to prevent failures from occurring in production.

Servlets Must Be Non-Blocking

SIP and HTTP Servlets must not block threads in the body of a SIP method. For example, no Servlet method should actively wait for data to be retrieved or written before returning control to the SIP Servlet container.

Store all Application Data in the Session

If you deploy your application to more than one engine tier server (in a replicated WebLogic SIP Server configuration) you must store all application data in the session as session attributes. In a replicated configuration, engine tier servers maintain no cached information; all application data must be de-serialized from the session attribute available in data tier servers.

All Session Data Must Be Serializable

To support in-memory replication of SIP application call states, you must ensure that all objects stored in the SIP Servlet session are serializable. Every field in an object must be serializable or transient in order for the object to be considered serializable. If the Servlet uses a combination of serializable and non-serializable objects, WebLogic SIP Server cannot replicate the session state of the non-serializable objects.

Use setAttribute() to Persist All Changes to Session State

Use the SIP Session's setAttribute method to change attributes in a session object. If you set attributes in a session object with setAttribute, the object and its attributes are replicated in the data tier cluster. If you use other set methods to change objects within a session, WebLogic SIP Server cannot replicate those changes. Any time a change is made to an object that is in the session, call setAttribute to update that object across the data tier cluster. Likewise, use removeAttribute to remove an attribute from a session object.

Also note that the WebLogic SIP Server container does not modify the call state 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.

Instead, ensure that your Servlet code modifies the call state before calling setAttribute, as in:

  Foo foo = new Foo(..);

  foo.modifyState();

  appSession.setAttribute("name", foo);

send() Calls Are Buffered

If your SIP Servlet calls the send() method within a SIP request method such as doInvite(), doAck(), doNotify(), and so forth, keep in mind that the WebLogic SIP Server container buffers all send() calls and transmits them in order after the SIP method returns. Applications cannot rely on send() calls to be transmitted immediately as they are called.

Warning: Applications must not wait or sleep after a call to send(), because the request or response is not transmitted until control returns to the SIP Servlet container.

Mark SIP Servlets as Distributable

If you have designed and programmed your SIP Servlet to be deployed to a cluster environment, you must include the distributable marker element in the Servlet's deployment descriptor when deploying the application to a cluster of engine tier servers. If you omit the distributable element, WebLogic SIP Server will not deploy the Servlet to a cluster of engine tier servers.

The distributable element is not required, and is ignored if you deploy to a single, combined-tier (non-replicated) WebLogic SIP Server instance.

Observe Best Practices for J2EE Applications

If you are deploying applications that use other J2EE APIs, observe the basic clustering guidelines associated with those APIs. For example, if you are deploying EJBs you should design all methods to be idempotent and make EJB homes clusterable in the deployment descriptor. See Clustering Best Practices in the WebLogic Server 8.1 Documentation for more information.