Category: Weblogic pools configuration

As we have seen, Weblogic Work Managers provide a server-level configuration that allows administrators a way to set dispatch-policies to their Servlets and EJBs.

WebLogic Server also provides a programmatic way of handling work from within an application. This can be carried out via the CommonJ API. Weblogic Server implements the commonj.work and commonj.timers packages to handle concurrent programming of EJBs and Servlets.

The following code example shows how to lookup a CommonJ Work Manager (bound in the JNDI name “java:comp/env/wm/myWM”) and use it in a Servlet:

public class HelloWorldServlet extends HttpServlet {     public void doGet(HttpServletRequest req, HttpServletResponse res)        throws IOException {        PrintWriter out = res.getWriter();        try {           InitialContext ic = new InitialContext();           WorkManager wm = (WorkManager)ic.lookup              ("java:comp/env/wm/myWM");                wm.schedule(new Work(){           public void run() {           ExecuteThread th = (ExecuteThread) Thread.currentThread();           System.out.println("Self-tuning workmanager: " +             th.getWorkManager().getName());           }           public void release() {}           public boolean isDaemon() {return false;}           });        }        catch (Exception e) { e.printStackTrace();  }        out.println("<h4>Servlet responded!</h4>");        System.out.println("finished execution");      }  }

In Oracle Weblogic there is not specific setting for the Web server thread pool; in order to control the number of threads used by your application, you can simply create a Global or scoped WorkManager and configure it with MaxThreadConstraints.

Continue reading How to configure Oracle Weblogic Web server pool

If you do not explicitly assign a Work Manager to an application, it will use the default Weblogic Work Manager. A module can be assigned to your custom Work Manager by using the <dispatch-policy> element in the deployment descriptor. As an alternative, you can define new Work Managers in your deployment descriptors through the <work-manager> element and associate as well constraints to them. Let’s see how to apply both approaches for all supported descriptors (weblogic.xml, weblogic-ejb-jar.xml, weblogic-application.xml):

Applying a Work Manager in your Web applications (weblogic.xml)

If you want to apply your Work Manager policies in your Web applications, you can reference it through the wl-dispatch-policy element in the weblogic.xml file. In the following example, we are using the ExampleWM (that we have formerly created through the Web console):

<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">     <wl-dispatch-policy>ExampleWM</wl-dispatch-policy>  </weblogic-web-app>

Web applications can even reference a Work Manager at more granular level, such as at Servlet level, by setting the parameter wl-dispatch-policy as init parameter of your servlet. In the following example, we are associating the ExampleWM Work Manager with Servlet “WorkServlet”:

<web-app>   <servlet>     <servlet-name>WorkServlet</servlet-name>     <servlet-class>workservlet.WorkServlet</servlet-class>     <init-param>                           <param-name>wl-dispatch-policy</param-name>       <param-value>ExampleWM</param-value>     </init-param>   </servlet>  </web-app>

Applying a Work Manager in your EJBs (weblogic-ejb-jar.xml)

Work Manager can be as well bound to a specific EJB application by mentioning it into the dispatch-policy element of the weblogic-ejb.jar.xml. In the following example, we are binding the ExampleWM to our WorkEJB:

<weblogic-ejb-jar>     <weblogic-enterprise-bean>        <ejb-name>WorkEJB</ejb-name>        <jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name>        <dispatch-policy>ExampleWM</dispatch-policy>     </weblogic-enterprise-bean>  </weblogic-ejb-jar>

Applying a Work Manager in your application (weblogic-application.xml)

If you want to define a Work Manager and use it across all modules contained in EAR, then you can define it into the WLS Enterprise application descriptor named weblogic-application.xml file. In the following example, we are defining a Work Manager named JEEScopedWorkManager with Min and Max constraints:

<weblogic-application>    <max-threads-constraint>      <name>j2ee_maxthreads</name>      <count>50</count>   </max-threads-constraint>    <min-threads-constraint>      <name>j2ee_minthreads</name>      <count>1</count>   </min-threads-constraint>    <work-manager>      <name>JEEScopedWorkManager</name>   </work-manager> </weblogic-application>

Every application server makes use of thread pool to serve client requests. Weblogic has an advanced mechanism to manage its threads named Work Manager. The Work Manager effectively allows your applications to run concurrently in multiple threads and create rules/guidelines to follow when assigning requests to threads.

The default Work Manager which ships with Oracle Weblogic distribution should be sufficient for most basic applications; however, mission critical applications might want to customize the default Work Manager configuration. Essentially, there are three types of Work Managers, each one characterized by its scope and usage rules. The three types are:

• The default Work Manager
• Global Work Managers
• Application-scoped Work Managers

Weblogic Default Work Manager

At the highest level, in order to handle its thread management and perform self-tuning, Weblogic uses the default Work Manager. This Work Manager is used by an application when no other Work Managers are specified in the application’s deployment descriptors. In most cases, the Default Work Manager will be just enough; you can however override its behavior by creating and configuring a Global Work Manager named “default” (see recipe “Creating a Work Manager”). This allows you to control the default thread-handling behavior of Weblogic Server.

Global Work Manager

Global Work Managers have the scope of the domain. You can create them in the WebLogic Administration Console (see recipe “Creating a Work Manager”). This kind of Work Manager will apply to all applicationsdeployed on the application server.

Application Scoped Work Manager

You can also create Work Managers at application level by specifying them in the following descriptors:

• weblogic-application.xml
• weblogic-ejb-jar.xml
• weblogic.xml

If you do not explicitly assign a Work Manager to an application, it uses the default Work Manager.

See the Section “Using Work Managers in your applications” to learn how to define and reference Work Managers in Weblogic deployment descriptors.

As for any Java EE compatible application server, Oracle Weblogic ships with an EJB container that maintains a pool of stateless session beans to avoid creating and destroying instances. As for the Stateful counterpart, Oracle WLS creates SFSBs instances as they are needed to service client requests. Between requests, these instances reside in a bean-specific cache in the active state, ready for the next request. Both types of EJB endpoints can be configured through an Oracle WSL custom deployment descriptor named weblogic-ejb-jar.xml that is used to override or enhance the configuration provided by the standard ejb-jar.xml file. Next section will show how to do it:

Configuring Oracle Weblogic Stateless EJB pool

The stateless pool configuration is composed of two parameters: a lower and an upper bound.

• The upper bound is specified by the max-beans-in-free-pool parameter. It should be set equal to the number of threads expected to invoke the EJB concurrently. Using a too small value will impact concurrency. 
• The lower bound is specified by the initial-beans-in-free-pool parameter. Increasing the value of initial-beans-in-free-pool increases as well the startup time for the server. The advantage is that the cost of creating EJB instances is not incurred at run time.

Both elements can be defined as part of the weblogic-ejb-jar.xml within a “pool” stanza:

<weblogic-enterprise-bean>     <ejb-name>MessageExporterSessionEJB</ejb-name>        <stateless-session-descriptor>           <pool>              <max-beans-in-free-pool>10</max-beans-in-free-pool>              <initial-beans-in-free-pool>10</initial-beans-in-free-pool>           </pool> . . . .  </weblogic-enterprise-bean>

Configuring Oracle Weblogic Stateful EJB cache

The size of the SFSB cache, is on the other hand, defined by the max-beans-in-cache element in the weblogic-ejb-jar.xml deployment descriptor file. The default value is 1000. Here’s a sample configuration which limits this value to 200 units:

<weblogic-enterprise-bean>      <ejb-name>AccountBean</ejb-name>      <stateful-session-descriptor>          <stateful-session-cache>              <max-beans-in-cache>200</max-beans-in-cache>              <idle-timeout-seconds>1200</idle-timeout-seconds>          </stateful-session-cache>      </stateful-session-descriptor>  </weblogic-enterprise-bean>

You should set this value to the expected number of concurrent stateful EJB clients in order to avoid excessive bean passivation and activation. Consider that setting this value too high will consume memory unnecessarily.