Tuesday Sep 02, 2014

Oracle WebLogic Server 12.1.3 - Live WebCasts coming during September

Hello - 

The WebLogic Server Curriculum Development group is hosting a 3 part series of live webcasts to highlight three of the new manageability features in Oracle WebLogic Server 12.1.3:  whole server migration (including JMS) for dynamic clusters, REST-based management improvements, and Oracle Fusion Middleware Control improvements for managing Oracle WebLogic Server 12.1.3.   The schedule for topics is given below.  

Mark Lindros, who has many years of experience with Oracle WebLogic Server, as a user and courseware developer, will be delivering the webcasts.   For more details on content see Mark's blog.  All of the Events will also be recorded and posted to the Oracle Learning Library.  This is an excellent opportunity to learn about new features in Oracle WebLogic Server 12.1.3.   Hope to see you there.


Oracle WebLogic Server 12.1.3: Using Whole Server Migration with Dynamic Clusters

Date: Wednesday, September 3rd, 2014 Time: 9:00 am US/Pacific time


This webcast will demonstrate how to configure whole server migration for clusters that contain dynamically created servers. Watch as JMS messages are placed on a queue on one server, that server is automatically migrated to another machine, and the same JMS messages are accessible by the migrated server.

To access the content this event is based on, click here

Oracle WebLogic Server 12.1.3: Using REST Services to Manage WebLogic Server

Date: Wednesday, September 10th, 2014 Time: 9:00 am US/Pacific time


This webcast demonstrates how to use RESTful requests to manage a WebLogic Server domain. Learn how to format REST requests to start and stop servers and clusters, manage application deployments, and manage JDBC data sources... all from the command-line!

To access the content this event is based on, click here

Oracle WebLogic Server 12.1.3: Using Fusion Middleware Control to Manage WebLogic Server

Date: Wednesday, September 17th, 2014 Time: 9:00 am US/Pacific time


This webcast demonstrates how to use Fusion Middleware Control (FMWC) to manage a WebLogic Server domain. Learn how to use FMWC to view domain statistics, start and stop servers and clusters, manage application deployments, manage JDBC data sources, and manage users and groups without using the WebLogic administration console.

To access the content this event is based on, click here

Friday Aug 15, 2014

Coming to OpenWorld? A must attend session…

NTT Docomo, Inc. is the predominant mobile phone operator in Japan. The name is officially an abbreviation of the phrase, "do communications over the mobile network", and is also from a compound word dokomo, meaning "everywhere" in Japanese. 

One of the most important of NTT Docomo’s systems is ALADIN, which is a nationwide operating system shared with its eight regional subsidiaries. ALADIN has five primary functions: customer management, phone number management, information processing and storage, sales information management, and credit investigation. To enhance cost efficiency and help ensure stable operation of ALADIN, NTT Docomo has employed Oracle WebLogic Server as a new application platform. Further information on this can be found here.

Last year at OpenWorld, NTT Docomo was honored as an Innovation Award Winner for:

· Implementing real time sales and contract management system enabling all services requested by customers for immediate activations before customer leaves the Docomo store

· A robust disaster recovery strategy, room to grow the business, and ability to move custom Java development to a platform with built in standards - WebLogic

· Better performance, better reliability, better stability, and smooth migration

Meet This Year's Most Impressive Innovators!

This year we continue to honor customers for their most innovative and cutting-edge solutions using Oracle Fusion Middleware. Join us in celebrating award recipients’ great achievements and commitment to innovation.  

Oracle Fusion Middleware: Meet This Year's Most Impressive Innovators

Session ID: CON7029

Tuesday September 30, 2014 @ 5-5:45 pm (PST)

Yerba Buena Center for the Arts 
YBCA Theater (next to Moscone North)

700 Howard St., San Francisco, CA, 94103

Sunday Aug 10, 2014

Data Source Encrypted Connection Properties and SSL

Encrypted properties are needed for information that needs to be secured instead of exposing it as clear text.  For data sources, that's generally for security credentials like passwords.  Since the first release, WLS data source has only supported a single encrypted property, the database password corresponding to the database user for all connections on the data source.  That was fine for simple security but adding features like SSL needed additional passwords for the key store and trust store.  We figured out a limited solution by using the Oracle auto-login wallet with store type SSO that did not require an additional password value.  That's documented at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#CHDBBIJH .  

We explored options for supporting additional encrypted properties including encrypting all properties with the name "Password" but it didn't seem to be an elegant solution.  In 10.3.6, we made a simple extension to connection properties to support system properties.  In WLS 12.1.3, we made a similar extension to support encrypted properties.  A JDBC property now consists of a name and a choice of a value, a system property value, or an encrypted value.  Encrypted values would commonly be used for javax.net.ssl.trustStorePassword and/or javax.net.ssl.keyStorePassword when configuring SSL.

You can set the encrypted property in a WLST script using


The clear text value (literal or variable) is encrypted and then stored as an encrypted value in the descriptor.  This works for both on-line and off-line WLST.  If you have an on-line WLST script, you can also use


In this case, the encryption is automatically done and the encrypted value is stored.

You can also use the WLS administration console to create encrypted properties.  It's not possible to specify the encrypted values when creating a data source.  That is, the creation assistant doesn't support encrypted properties.  When you create a data source, you might need to put in a clear-text password if you want to test the connection during the creation process. You can add encrypted values to the data source definition by editing the configuration. You need to go to the Configuration Connection Pool tab (the same tab as normal properties and system properties). If you used clear-text passwords during creation for testing, you will need to remove the clear text values first.   There are two approaches to add encrypted values.  One is to type the name and clear text value directly into the Encrypted Properties text box.  When you click on the Save button, the values are encrypted.  The advantage of this approach is that you can enter multiple values directly but the downside is that between the text entry and saving the values, the values are visible on the screen.  This approach is shown in the following figure.

There is a second approach that provides secure data entry.  Note in the picture above, there is an "Add Securely" button to the right of the Encrypted Properties text box.  Clicking on that button causes a new window to pop up as in the following figure. You can enter the property name and then the encrypted value twice.  The input for the encrypted values is obscured.  When done, click on the OK button to enter the name and encrypted value in the Encrypted Properties text box.  The advantage of this approach is that the clear text value is never displayed.

You can see the product documentation for encrypted properties at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#CHDGCDIB,  including some code examples.

The timing was good for this feature because a lot of testing was done on setting up one-way and two-way SSL configurations in the Server for WLS 12.1.3.  See http://docs.oracle.com/middleware/1213/core/ASADM/sslconfig.htm#CBDFGCAF  for a discussion of using SSL with the data tier.  This release also introduced FIPS 140 support in Oracle Fusion Middleware.  See http://docs.oracle.com/middleware/1213/core/ASADM/fips.htm  for more details. 

WLS 12.1.3 has a complete SSL security solution that is well tested and well documented.  Support for encrypted data source connection properties is one important piece in the solution.

P.S. Earlier versions of the documentation said "You must enable the Oracle PKI provider. This can either be done statically by updating the java.security file under the JRE or dynamically by setting it in a WLS startup class ...".  Updating the JRE java.security file was removed from the documentation in WLS 12.1.3 because testing found that it didn't work for two-way SSL. A bug was fixed in the oraclepki.jar file late in 12.1.3 and this approach now works. It may be the easier of the two approaches.

Monday Aug 04, 2014

Setting V$SESSION for a WLS Datasource

Every Oracle database connection runs in the context of a database process called a session.  There is a v$session view that contains a lot of information about the database sessions that are active.. By default when you use the Oracle Thin Driver, the value v$session.program is set to "JDBC Thin Client".  That separates out the Java applications from sqlplus and the scores of database background programs but doesn't provide much additional information since all of the Java connections look the same.  It's easy to set this and some other values on v$session using connection properties on the Oracle Thin driver.  The following connection properties are supported:  v$session.osuser, v$session.process, v$session.machine, v$session.terminal, and v$session.program.  Setting these will set the corresponding value on the session on the database side.  These values are then available from the v$session view.

The simple approach is to hard-code a value into a normal connection Property.  That's fine if you want to associate a fixed value with a data source.  It's more interesting if you dynamically set the value at runtime. For example, if there are multiple servers running within a domain and the information needs to be server specific, a normal cluster deployment with one fixed value is not useful, and the option of deploying the DataSource to every server individually and then hand-editing each one's descriptor with unique values for these properties is not manageable. You can easily handle this using a System Property.  The value that is specified is taken to be a Java system property that you set on the command line of the application server.  It is retrieved using System.getProperty() and set as the value of the connection property.    There's a new Encrypted Property in WLS 12.1.3; I'll write another article about that.

If you use bin/startWebLogic.sh to start the server, it will put -Dweblogic.Name=${SERVER_NAME}on the command line.  If you set the v$session.program System Property connection property to "weblogic.Name", your session program value will match the WLS server that is making the connection. 

You can set connection properties by editing the data source configuration on the "Connection Pool" tab in the WebLogic administration console.  Properties are set in the Properties and System Properties text boxes.  Let's say that I set four of the values to test values and one to a system property, generating the descriptor fragment as follows.


Alternatively, you could set these values using on-line or off-line WLST.

Here's a fragment of an off-line WLST script.

cd('/JDBCSystemResource/myds/JdbcResource/myds') cd('JDBCDriverParams/NO_NAME_0') cd('Properties/NO_NAME_0') create('v$session.program','Property') cd('Property') cd('v$session.program') set('SysPropValue', 'weblogic.Name')

If $SERVER_NAME is myserver and I then go to run a query, here is the resulting output.

SQL> select program, osuser, process, machine, terminal 
  from v$session where program = 'myserver';
myserver test1 test2 test3 test4

If the server names aren't obvious enough, you could set the program to "WebLogic Server $SERVER_NAME".  You could set -Djdbc.process=<PID> to tie connections to a specific WLS server process. You might want to add the WLS data source name to the program value.  You could set osuser to the Java value "user.name".

 Using system properties can make this a powerful feature for tracking information about the source of the connections, especially for large configurations.

Friday Aug 01, 2014

Using 3rd party JDBC Jar Files

If you look at the documentation for adding a 3rd party JDBC jar file, it recommends adding it to the system classpath by updating comEnv.sh.  See http://docs.oracle.com/middleware/1212/wls/JDBCA/third_party_drivers.htm#JDBCA233.  However, there more options with some advantages and disadvantages.  To use some of these options, you need to know something about application archive files.

The general precedence of jar files in the classpath is the following:

system classpath >> DOMAIN_HOME/lib >> APP-INF/lib >> WEB-INF/lib

The highest priority is given to jar files on the system classpath.  The advantage of using the system classpath is that it works for all environment including standalone applications. 

The rest of the options only work for applications deployed in the application server.  That includes the WLS administration console and WLST but not an application like 'java utils.Schema'.  These approaches work on WLS 10.3.6 and later.

The simplest way to add a jar file when you don't need it accessed in a standalone application is to drop it in DOMAIN_HOME/lib.  This is an easy way to access a driver for a data source in the application server. It won't work for jar files that are shipped with WLS and already part of the system classpath because the system classpath takes precedence.  That's why this article focuses on "3rd party" jar files.  More information and recommendations about using DOMAIN_HOME/lib can be found at http://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#i1096881 .

APP-INF/lib will only work in an EAR file and applies to all applications in the EAR file.  APP-INF is located at the root directory in the EAR file at the same level as META-INF.  This approach and the next have the advantage of packaging the driver with the application archive.  However, it's not efficient if the driver is needed by more than one archive and you probably should use DOMAIN_HOME/lib.

WEB-INF/lib only works in a WAR file and must be located at the root directory in the WAR file.  It only applies to the corresponding web application.  By using a WEB-INF/weblogic.xml file that has "<prefer-web-inf-classes>true</prefer-web-inf-classes>", the jar files in WEB-INF/lib take precedence over others (that is, the default precedence defined above is overridden).  This is useful if you want different versions of the driver for different applications in various WAR files.   Note that starting in WLS 12.1.1 with Java EE 6 support, it's possible to have a standalone WAR file that is not embedded in an EAR file.

Here's an indented list that attempts to capture the hierarchy of the files and directories described above in EAR and WAR files.

Application (ear)

  • Web module (war)
    • WEB-INF/lib
    • WEB-INF/web.xml
    • WEB-INF/weblogic.xml
  • EJB module
  • APP-INF/lib

There is sample code for a WAR file at this link.  The data source definition can appear either as a descriptor in web.xml or as an annotation in the java file.  weblogic.xml can be used to set prefer-web-inf-classes appropriately.  The @Resource annotation is used to reference the data source in the application code.  This program prints the version of the driver.  You can play with two versions of the Derby driver to see how the precedence works.

Note:  You can't have two versions of the same jar in both domain/lib or the system classpath and  WEB-INF/lib or APP-INF/lib with prefer-web-inf-classes or prefer-application-packages set.  That is, either you use domain/lib or system classpath to get it into all applications in the domain or you use it embedded in the application but not both.  If you don't follow this restriction, it's possible (depending on the jar, the version changes, and the order in which the jars are referenced) that a ClassCastException will occur in the application.

The choice of where you locate the JDBC jar file depends on your application.  For standalone application access, use the system classpath.  For simple access in all or most applications, use DOMAIN_HOME/lib.  For access across an EAR file, use APP-INF/lib.  For access within a single WAR file, use WEB-INF/lib.

Sunday Jul 27, 2014

Data Source Connection Labeling

The connection labeling feature was added in WLS release 10.3.6. This feature has the potential to reduce the overhead when there is work to initialize a connection for application use. Labeling connections allows an application to attach arbitrary name/value pairs to a connection. The application can request a connection with the desired label from the connection pool. By associating labels with connection states, an application can retrieve an already initialized connection from the pool and avoid the time and cost of re-initialization. This feature is described in good detail including an example at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_labeling.htm .

Connection Labeling is enhanced in release WLS 12.1.3.  For some applications, it's possible that making a connection conform if it doesn't match can be so expensive that a new connection should be created instead of using an existing connection but only up to some threshold.  The enhancement introduces the notion of a "high-cost connection".  There are two new connection properties that can be configured on the data source descriptor.

New Connection Property Default Value Usage
ConnectionLabelingHighCost Integer.MAX_VALUE If connection label cost >= this value, considered high-cost connection.
HighCostConnectionReuseThreshold 0 When > 0, number of connections in pool when high-cost connections are re-used

This following list spells out the rules in more detail when getting a connection using labeling properties. All available connections are evaluated to get their cost using the registered labeling callback.

  • If the cost for a connection is greater than or equal to ConnectionLabelingHighCost, it is a High-Cost Connection.
  • When the lowest-cost available connection is a High-Cost Connection, test current pool size against Reuse High-Cost Connection Threshold and against minimum pool size.
  • If the current connection count is less than the minimum or threshold values, return a new connection instead of the high-cost connection.
  • Otherwise (current connection count is greater than or equal to the threshold), return the lowest-cost High-Cost Connection.
  • Labeled connections with cost value Integer.MAX_VALUE will never be reused (same as prior release).
  • The maximum pool size constraint still holds (i.e. if threshold > maximum pool size, maximum pool size governs).
  • The minimum pool size constraint holds (i.e. if threshold < minimum pool size, minimum pool size governs).
  • Leaving the threshold unset results in same behavior as threshold = minimum (i.e., if current >= minimum, return the lowest-cost connection, which in this case is a High-Cost Connection).
  • When there are no available connections, use the standard behavior.  That is, return a new connection subject to maximum pool size.  If the current size is greater than or equal to the maximum pool size, wait for a connection to be available, subject to the timeout, etc.

Here is a simplified sample configuration file.

    <test-table-name>SQL ISVALID</test-table-name>

The connection labeling properties can be configured in the properties text box in the administration console or can be created using WLST. In this example, a high cost connection has a cost greater than or equal to 5.  The threshold is 20 connections, which is greater than the initial capacity of 0 and less than the maximum capacity of 25 so there is no interference.  Note that in the configuration above, the connection labeling callback is registered in the configuration file; alternatively it can be registered in the application code.

The following table describes the behavior when ConnectionLabelingHighCost=5 and HighCostConnectionReuseThreshold=20 for various values of connection labeling cost. 

Total Connections in Pool Minimum cost connection available Action
0-19 None available Create new connection
0-19 0-4 Use existing connection
0-19 >=5 Create new connection; don't use high-cost connection
>=20 None available Create new connection
>=20 0-4 Use existing connection
>=20 5 Use existing high-cost connection

There is a sample program for handling PDB switching in a Multi-Tenant Database environment using connection labeling at https://blogs.oracle.com/WebLogicServer/entry/part_3_12c_database_and . The sample uses the label to keep track of the PDB associated with each connection.  The sample can't take advantage of this new feature because it always returns Integer.MAX_VALUE for a mismatch so the connections will never be reused. Instead, we could return some value that is equal to the configured ConnectionLabelingHighCost. Just by changing Integer.MAX_VALUE to 5 in the callback, we will create new connections up to 19 connections and then start reusing connections.

The connection labeling feature  processing isn't free.  The connection cost is computed for all available connections every time a connection is reserved.  But in the case that connection initialization is expensive, it can perform much better.

Thursday Jul 24, 2014

Improved High Availability with Whole Server Migration on Dynamic Clusters

If you remember, we added Dynamic Clusters in WebLogic Server 12.1.2. Dynamic Clusters make it really easy to configure a cluster and to scale up that cluster. They are a cloud-enabling technology that provides elasticity for your applications. We’re always looking to improve on a good thing, so in WebLogic Server 12.1.3, we enabled Whole Server Migration with Dynamic Clusters. Whole Server Migration enhances the availability of clusters by enabling a failing/failed managed server to be restarted automatically on a different machine. This is especially important for recovery of persistent JMS messages and distributed transactions.

I just posted a video on YouTube with more details and a short demo. Take a look:

If you want to learn more:

Wednesday Jul 23, 2014

Developing Java EE applications with Maven and WebLogic 12c

Like many other developers, Zemian Deng is finding the new Maven support in WebLogic 12c quite slick.

Check out his post at buff.ly/1qv3tqi to learn a few useful tips.

Thursday Jul 17, 2014

Exciting New JTA 12.1.3 Feature “XA Transaction without Transaction Logs”

One of the most exciting new features in WebLogic Server 12.1.3 is a JTA new feature
“XA Transaction without Transaction Logs.” This feature does not only provide performance optimization when applications use XA transactions, but also has great advantages for Disaster Recovery scenarios.

XA transactions provide a standards-based mechanism to preserve data integrity for mission-critical applications. Traditionally XA transaction recovery requires the transaction manager to persist transaction records to stable storage (TLog) after all of the transactions resources have been prepared, and purging them after all of the transactions resources have been completed. However, recording pending transactions for recovery purposes requires additional I/O which affects performance. In cases of disaster recovery transaction logs need to be replicated to make sure that global transactions can be recovered.

XA Transaction without Transaction Logs,” uses a determiner resource which can be either a DataSource or a WebLogic JMS resource to determine the recover outcome of pending transactions. When using a determiner resource, WebLogic Server will no longer write and purge transaction checkpoints to TLogs. XA Transaction without Transaction Logs,” takes advantage of the two-phase-commit protocol, as well as prepare and commit ordering of resources participating in the global transaction to determine if pending transactions need to be recovered with a commit or a rollback.

The advantages of this feature are:

· Up to three times performance throughput improvement

· Prepare and Commit ordering

· I/O latency removed by not writing to TLOG (default file store)

· Resource and/or batch blocking removed (JDBC Tlog)

· Memory consumption reduced

· Capacity requirements reduced

· TLOG replication made easy

In WebLogic Server 12.1.3 “XA Transaction without Transaction Logs,” is restricted to transactions that involve a single Transaction Manager (WebLogic Server). The mixture of transactions that enlist determiner resources and span single Transaction Managers, with those who do not enlist a determiner resource and/or span multiple Transaction Managers is supported. In the future, WebLogic will support not logging transactions that involve multiple Transaction Managers.

Check out the YouTube recordings that go into detail how this feature works "JTA 12.1.3 New Feature and Optimization". There is even a demo that shows you how it is configured, how it works, and how you can debug your transactions to verify if the determiner is working "XA Transaction without Transaction Logs" and Demo.

Refer to the WebLogic Server 12.1.3 documentation JTA documentation "XA Transaction without Transaction Logs" for further details on how to configure and use the feature.

Monday Jun 30, 2014

Oracle WebLogic Server 12.1.3 Whitepaper - Developing with WebLogic Server

One of the most significant areas of investment in WebLogic Server 12.1.3 has been in developer productivity and API updates, as I summarized in my blog from last week.   However, a brief summary is typically not enough for developers who want a more detailed description of the improvements we have delivered.   And although product documentation contains all of the relevant updates, sometime it does not capture the overall background on the topic that puts the improvements into context.  

Steve Button from the WebLogic Server product management team has published an excellent whitepaper on OTN - Oracle WebLogic Server 12.1.3 Whitepaper - Developing with WebLogic Server - which provides a detailed description of the new features, along with the background which explains why we delivered the improvements, and the benefits they offer.   The whitepaper covers new WebLogic Server 12.1.3 features in the areas of WebSocket, JSON, JAX-RS, JPA, Server-Sent Events, Maven and more.

If you are a WebLogic Server user looking for a detailed description of the latest development features in WebLogic Server 12.1.3, and how you can leverage them in your applications, this is an excellent resource.   Please take a look!

Thursday Jun 26, 2014

Oracle WebLogic Server 12.1.3 is Released

We're proud to announce that Oracle WebLogic Server 12.1.3 has been released as part of the Cloud Application Foundation and Oracle Fusion Middleware 12.1.3 release as described at the Cloud Application Foundation Blog. Oracle WebLogic Server is the industry's leading application server, providing unparalleled choice for deploying applications in public clouds, on-premise private clouds, engineered systems such as Oracle Exalogic Elastic Cloud, Oracle SPARC SuperClusters, and Oracle Database Appliance systems, and conventional systems.

Oracle WebLogic Server 12.1.3 is a new version release of Oracle WebLogic Server 12c.   It builds on the features provided in WebLogic Server 12.1.2 to improve developer productivity, performance and high availability, and manageability.   It enables you to develop and deliver innovative applications, to meet the application service level requirements for your business, and to manage your application infrastructure efficiently to achieve low total cost of ownership.

For developers we have placed specific focus on enabling development of server applications that support rich client applications running in HTML5 browsers or mobile devices. Such applications typically rely on REST based Web Services, use JSON as the data format for message payloads, and often require dynamic updates between clients and servers. In Oracle WebLogic Server 12.1.3, we have implemented support for selected Java EE 7 APIs including JAX-RS 2.0, Java API for JSON Processing, Java API for WebSocket, and JPA 2.1, to enable and support development of such applications.  We have also delivered related value-added capabilities like support for Server-Sent Events and unique WebSocket emulation capability.

High availability and performance improvements include improvements to Oracle Database 12c integration support - we have bundled the latest version of the Oracle Database 12c driver for ready access to database integration features, and have certified Oracle Database 12c AQ JMS as a Foreign JMS Server within Oracle WebLogic Server.    Innovations to the Oracle WebLogic Server transaction processing subsystem enable elimination of transaction logs in many cases, increasing performance and simplifying distaster recover configuration.   Optimizations for Oracle Exalogic systems include JMS performance improvements, and Cooperative Memory Management to adapt server memory usage based on memory consumption on Oracle Exalogic systems.

Manageability enhancements include improvements to dynamic clusters introduced in Oracle WebLogic Server 12.1.2.   In Oracle WebLogic Server 12.1.3 we support use of whole server migration to provide improved availability for dynamic clusters environments using JMS.    We have expanded our support for REST-based management, adding lifecycle management, application deployment, and datasource configuration support via REST.   We have also made similar improvements to support for Oracle WebLogic Server management in Oracle Fusion Middleware Control.

Finally, Oracle WebLogic Server 12.1.3 is the foundation of the Oracle Fusion Middleware 12.1.3 release, which adds Oracle SOA Suite 12c and other Oracle Fusion Middleware products to the family of products that is supported with Oracle WebLogic Server 12c.  This will make it easy for Oracle WebLogic Server 12.1.3 customers to adopt the latest releases of these products, and will also enable Oracle Fusion Middleware users to take advantage of the latest features in WebLogic Server 12.1.3.  To learn more:

...and look for more information from us in the coming days and weeks.  Thanks!

Indian Government Organization Saves $125,000 with Real-Time Insight for Decision-Making

Chhattisgarh Infotech and Biotech Promotion Society (CHiPS) is run by the government of Chhattisgarh, which became India’s newest and tenth-largest state in November 2000. CHiPS deployed Oracle WebLogic Server Enterprise Edition with Oracle WebCenter products as well as Oracle Web Tier to automate document workflow processes and provide a consistent and transparent decision-making process to meet statutory requirements. It reduced paper and document management costs by US$125,000 in one year, extended visibility for decision-making processes, enhanced collaboration between departments, increased business productivity through anytime-anywhere access to information, and enhanced citizen satisfaction. For more details, read this customer snapshot.

Monday Jun 16, 2014

Detailed Analysis of a Stuck Weblogic Execute Thread Running JDBC Code

The following thread was extracted from a thread dump taken on a JVM instance running WebLogic Server.

In this post I will deconstruct this thread and describe the data it contains and the potential issues it may illuminate.

[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)' id=73 idx=0x128 nid=13410 prio=1 alive, in native, daemon 

 java.net.SocketInputStream.socketRead0(Native Method)


oracle.net.ns.Packet.receive(Unknown Source)

oracle.net.ns.DataPacket.receive(Unknown Source)

oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)

oracle.net.ns.NetInputStream.read(Unknown Source)










com.foo.abc.util.ConnectionPool.createConnection(Unknown Source)

This thread is considered Stuck by WebLogic because it's been running for over the time defined in MaxStuckThreadTime (600 seconds by default). Weblogic Server waits for this time to be reached before marking a thread as stuck if the thread is still working after this time.  If you deem that 600 seconds is too long before a running thread is considered stuck then you can change the value of the this parameter using the WebLogic Console (as shown below), or use setMaxStuckThreadTime from the ServerFailureTriggerMBean interface.

An error including BEA-000337 will be logged in the server log file when the thread changes its status to stuck but the server won't take further action on this thread.  However, you might want to investigate why this thread is taking such a long time to process the work assigned to it.

Lets now look at the thread itself.  From its header, you can spot the thread identifier (2 in this example) and the queue where it originated.  The term Self-tuning indicates that the associated thread pool consistently checks the overall throughput to determine if the thread count should change.

id (or tid) is the thread identifier, a unique process-wide number that identifies this thread within the JVM process.  This id is unique but can be reused by another thread once this thread is terminated. 

nid is the OS-level native thread identifier.  It can be used effectively to correlate with high CPU usage threads identified at the OS level (e.g. with Linux watch command).  See Unexpected High CPU Usage with WebLogic Server (WLS) Support Pattern (Doc ID 779349.1) for detailed steps.

idx is the thread index in the threads array.

prio refers to the thread priority, a number inherited from the thread that created it.  You can learn more about thread priorities at Class Thread but basically threads with higher priority are executed in preference to threads with lower priority.

alive refers to the fact that this thread has not ended yet and is still active.  

in native means that the thread uses the operating system's native ability to manage multi-threaded processes.  

daemon indicates that this thread can't prevent the JVM from exiting.

The thread header is accompanied with a full java stack which lists each method and class invoked since the first assignement to the thread up to its most recent action. This thread consists of obtaining a connection to an Oracle database using a Type 4 JDBC driver and then issuing a call but getting no response from the back end database server.  The database failed to respond, and the thread has probably been in the same waiting mode (unchanged and not progressing java stack) for a long time since it's now considered stuck; the most recent invocation being java.net.SocketInputStream.socketRead0.

At this point the back end database needs to be checked to understand why it's not responding to the java thread request.  A starting point could be to query v$session to find potential blocking sessions at the database level.

Blocking sessions occur when one session holds an exclusive lock on an object and doesn't release it.

Needless to say, the communication with the database needs to be confirmed as healthy with none to very limited latency.  Firewall issues should be ruled out as well.  Firewalls could time out idle sockets used by JDBC connections to the database and lead to not closing the socket the JDBC driver is using.

Tuesday May 13, 2014

WebLogic 12c Distinctive Recipes: Architecture, Development and Administration

Dr. Frank Munz, one of our most esteemed Oracle Aces, has just released an updated book on Oracle WebLogic 12c, which contains more than 130 additional pages, half a dozen new webcasts and more than 16 new or rewritten recipes.
From the book abstract:
Imagine you need to know about a problem with your car's engine. You could plough through the 1000-page manual. Or you could chat to the mechanic over a cup of coffee. That's WebLogic 12c Advanced Recipes. It's WebLogic for software architects, administrators and developers. For people like you who know quite a bit about WebLogic. What you don't want is the typical 'recipe book' full of screenshots. Click here. Click there. Do this. Do that. That's WebLogic by numbers. What you really want are the things you won't find in the manual, like recommendations, discussions, best practices, deployable projects, webcast videos and directions on when to use a feature - and when not to. With all this and more, this book is the perfect complement to official courses and manuals. In short, this gem of a book is almost as good as attending one of Frank's renowned workshops.

Friday May 09, 2014

BA, the German federal employment agency, ensures labor market services availability and performance

Bundesagentur für Arbeit (BA), the German federal employment agency, is the leading provider of labor-market services in Germany. With more than 100,000 employees, BA is the largest German government agency and one of the largest employers in the country. Supporting more than 6 million customers and a rapidly growing IT department, BA needed an application infrastructure and management solution that could help to increase IT efficiency while decreasing complexity. To provide a comprehensive solution for its Oracle application platform, the agency decided to deploy Oracle WebLogic Server and Oracle Enterprise Manager. The combination provided BA with the availability, scalability, and performance to meet critical requirements, such as on-time job placements and compensation provisioning—while significantly reducing IT administration costs. Get more details from the recent BA case study and review their press release.

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« May 2015