Tuesday Sep 29, 2015

Multi Data Source Configuration for Database Outages

Planned Database Maintenance with WebLogic Multi Data Source (MDS)

This article discusses how to handle planned maintenance on the database server when it is accessed by WebLogic Multi Data Source (MDS) in a fashion that no service interruption occurs.

To ensure there is no service interruption there must be multiple database instances available so the database can be updated in a rolling fashion.  Oracle technologies to accomplish this include RAC cluster  and GoldenGate or a combination of these products (note that DataGuard cannot be used for planned maintenance without service interruption).  Each database instance is configured as a member generic data source, as described in the product documentation.  This approach assumes that the application is returning connections to the pool on a regular basis.

Process Overview

1. On mid-tier systems - Shutdown all member data sources associated with the RAC instance that will be shut down for maintenance. It's important that not all data sources in each MDS list be shutdown so that connections can be reserved on the other member(s). Wait for data source shutdown to complete. See http://docs.oracle.com/cd/E13222_01/wls/docs100/wlsmbeanref/mbeans/JDBCDataSourceRuntimeMBean.html?skipReload=true#shutdown.

2. At this point, it may be desirable to do some work on the database side to reduce remaining connections not associated with WLS data source. For the Oracle database server, this might include stopping (or relocating) the application services at the instances that will be shut down for maintenance, stopping the listener, and/or issue a transactional disconnect for the services on the database instance.  See https://blogs.oracle.com/WebLogicServer/entry/agl_database_outages for more information that is included in the Active GridLink description.

3. Shutdown the instance immediate using your preferred tools

4. Do the planned maintenance.

5. Start up the database instance using your preferred tools

6. Startup the services when the database instances are ready for application use.

7. On midtier systems -Start the member data sources. See See http://docs.oracle.com/cd/E13222_01/wls/docs100/wlsmbeanref/mbeans/JDBCDataSourceRuntimeMBean.html?skipReload=true#start.

Shutting down the data source

Shutting down the data source involves first suspending the data source and then releasing the associated resources including the connections. When a member data source in a MDS is marked as suspended, the MDS will not try to get connections from the suspended pool but will go to the next member data source in the MDS to reserve connections. It's important not all data sources in each MDS list be shut down at the same time. If all members are shut down or fail, then access to the MDS will fail and the application will see failures.

When you gracefully suspend a data source, which happens as the first step of shut down:

- the data source is immediately marked as suspended at the beginning of the operation so that no further connections will be created on the data source

- idle (not reserved) connections are not closed but are marked as disabled.

- after a timeout period for the suspend operation, all remaining connections in the pool will be marked as suspended and “java.sql.SQLRecoverableException: Connection has been administratively disabled. Try later.” will be thrown for any operations on the connection, indicating that the data source is suspended. These connections remain in the pool and are not closed. We won't know until the data source is resumed if they are good or not. In this case, we know that the database will be shut down and the connections in the pool will not be good if the data source is resumed. Instead, we are doing a data source shutdown which will close all of the disabled connections.

The timeout period is 60 seconds by default. This can be changed by configuring or dynamically setting Inactive Connection Timeout Seconds to a non-zero value (note that this value is overloaded with another feature when connection leak profiling is enabled). There is no upper limit on the inactive timeout. Note that the processing actually checks for in-use (reserved) resources every tenth of a second so if the timeout value is set to 2 hours and it's done a second later, it will complete a second later.

Note that this operation runs synchronously; there is no asynchronous version of the mbean operation available. It was designed to run in a short amount of time but testing shows that there is no problem setting it for much longer. It should be possible to use threads in jython if you want to run multiple operations in one script as opposed to lots of script (a jython programmer is needed).

This procedure works for MDS configured with either Load-Balancing or Failover.

This is what a WLST script looks like to edit the configuration to increase the suspend timeout and then use the runtime MBean to shutdown a data source. It would need to be integrated into the existing framework for all WLS servers/data sources.

java weblogic.WLST myscript2.py
import sys, socket, os
hostname = socket.gethostname()
# Edit the configuration to set the suspend timeout

cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource + '/JDBCConnectionPoolParams/' + datasource )

cmo.setInactiveConnectionTimeoutSeconds(21600) # set the suspend timeout


# Shutdown the data source

cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' + datasource )



Note that if MDS is using a database service, you cannot stop or relocate the service before suspending or shutting down the MDS. If you do,. MDS may attempt to create a connection to the now missing service and it will react as though the database is down and kill all connections, not allowing for a graceful shutdown. Since MDS suspend ensures that no new connections are created at the associated instance (and the MDS only creates connections on this instance, never another instance even if relocated), stopping the service is not necessary for MDS graceful shutdown. Also, since MDS suspend causes all connections to no longer do any operations, no further progress will be made on any sessions (the transactions won't complete) that remain in the MDS pool.

There is one known problem with this approach related to XA affinity that is enforced by the MDS algorithms. When an XA branch is created on a RAC instance, all additional branches are created on the same instance. While RAC supports XA across instances, there are some significant limitations that applications run into before the prepare so MDS enforces that all operations be on the same instance. As soon as the graceful suspend operation starts, the member data source is marked as suspended so no further connections are allocated there. If an application using global transactions tries to start another branch on the suspending data source, it will fail to get a connection and the transaction will fail. In this case of an XA transaction spanning multiple WLS servers, the suspend is not graceful. This is not a problem for Emulate 1PC or 2pc, which uses a single connection for all work, and LLR.

If there is a reason to separate the suspending of the data source, at which point all connections are disabled, from the releasing of the resources, it is possible to run suspend followed by forceShutdown. A forced shutdown must be used to avoid going through the waiting period a second time. This separation is not recommended.

To get a graceful shutdown of the data source when shutting down the database, the data source must be involved. This process of shutting down the data source followed by shutdown of the database requires coordination between the mid-tier and the database server processing. Processing is simplified by using Active GridLink instead of MDS; see the AGL blog included above.

When using the Oracle database, it is recommended that an application service be configured for each database so that it can be configured to have HA features. By using an application service, it is possible to start up the database without data source starting to use it until the administrator is ready to make it available and the application service is explicitly started.

Thursday Sep 10, 2015

Active GridLink Configuration for Database Outages

This article discusses designing and deploying an Active GridLink (AGL) data source to handle database down times with an Oracle Database RAC environment. 

AGL Configuration for Database Outages

It is assumed that an Active GridLink data source is configured as described "Using Active GridLink Data Sources" http://docs.oracle.com/middleware/1213/wls/JDBCA/gridlink_datasources.htm#JDBCA373   with the following.

- FAN enabled.  FAN provides rapid notification about state changes for database services, instances, the databases themselves, and the nodes that form the cluster.  It allows for draining of work during planned maintenance with no errors whatsoever returned to applications.

- Either auto-ONS or an explicit ONS configuration.

- A dynamic database service.  Do not connect using the database service or PDB service – these are for administration only and are not supported for FAN.

- Testing connections.  Depending on the outage, applications may receive stale connections when connections are borrowed before a down event is processed.  This can occur, for example, on a clean instance down when sockets are closed coincident with incoming connection requests. To prevent the application from receiving any errors, connection checks should be enabled at the connection pool.  This requires setting test-connections-on-reserve to true and setting the test-table (the recommended value for Oracle is “SQL ISVALID”).

- Optimize SCAN usage.  As an optimization to force re-ordering of the SCAN IP addresses returned from DNS for a SCAN address, set the URL setting LOAD_BALANCE=TRUE for the ADDRESSLIST in database driver and later.   (Before, use the connection property oracle.jdbc.thinForceDNSLoadBalancing=true.)

Planned Outage Operations

For a planned downtime, the goals are to achieve:

- Transparent scheduled maintenance: Make the scheduled maintenance process at the database servers transparent to applications.

- Session Draining: When an instance is brought down for maintenance at the database server draining ensures that all work using instances at that node completes and that idle sessions are removed. Sessions are drained without impacting in-flight work.  

The goal is to manage scheduled maintenance with no application interruption while maintenance is underway at the database server.  For maintenance purposes (e.g., software and hardware upgrades, repairs, changes, migrations within and across systems), the services used are shutdown gracefully one or several at a time without disrupting the operations and availability of the WLS applications. Upon FAN DOWN event, AGL drains sessions away from the instance(s) targeted for maintenance. It is necessary to stop non-singleton services running on the target database instance (assuming that they are still available on the remaining running instances) or relocate singleton services from the target instance to another instance.  Once the services have drained, the instance is stopped with no errors whatsoever to applications.

 The following is a high level overview of how planned maintenance occurs.

–Detect “DOWN” event triggered by DBA on instances targeted for maintenance

–Drain sessions away from that (those) instance(s)

–Perform scheduled maintenance at the database servers

–Resume operations on the upgraded node(s)

Unlike Multi Data Source where operations need to be coordinated on both the database server and the mid tier, Active GridLink co-operates with the database so that all of these operations are managed from the database server, simplifying the process.  The following table lists the steps that are executed on the database server and the corresponding reactions at the mid tier.

Database   Server Steps


Mid Tier Reaction

Stop the   non-singleton service without   ‘-force’ or relocate the singleton service.  

Omitting the –server option operates on all   services on the instance.

$ srvctl   stop service –db <db_name>
-service <service_name>
-instance   <instance_name


$ srvctl   relocate service –db <db_name>
-service <service_name> -oldinst   <oldins> -newinst <newinst>

The FAN Planned   Down (reason=USER) event for the service informs the connection pool that a service   is no longer available for use and connections should be drained.  Idle   connections on the stopped service are released immediately.  In-use connections are released when returned   (logically closed) by the application.    New connections are reserved on other  instance(s) and databases offering the   services.  This FAN action invokes draining the sessions from the   instance without disrupting the application.

Disable   the stopped service to ensure it is   not automatically started again. Disabling the service is optional. This step   is recommended for maintenance actions where the service must not restart   automatically until the action has completed. . 

$ srvctl   disable service –db <db_name> -service <service_name> -instance   <instance_name>

No new   connections are associated with the stopped/disabled service at the mid-tier.

Allow   sessions to drain.

The   amount of time depends on the application.    There may be long-running queries.    Batch programs may not be written to periodically return connections   and get new ones. It is recommended that batch be drained in advance of the   maintenance.

Check   for long-running sessions. Terminate   these using a transactional disconnect.    Wait for the sessions to drain.    You can run the query again to check if any sessions remain.

SQL>   select count(*) from ( select 1 from v$sessionwhere service_name in   upper('<service_name>') union all
select 1 from v$transaction where   status = 'ACTIVE' )
  SQL> exec

The   connection on the mid-tier will get an error.    If using application continuity, it’s possible to hide the error from   the application by automatically replaying the operations on a new connection   on another instance.  Otherwise, the   application will get a SQLException.

Repeat   the steps above.

Repeat   for all services targeted for planned maintenance

Stop the   database instance using the immediate option.

$ srvctl   stop instance –db <db_name>
-instance <instance_name> -stopoption   immediate

No   impact on the mid-tier until the database and service are re-started.

Optionally   disable the instance so that it will not automatically start again during   maintenance.

This   step is for maintenance operations where the services cannot resume during   the maintenance.

$ srvctl   disable instance –db <db_name> -instance <instance_name>

Perform   the scheduled maintenance work.

Perform   the scheduled maintenance
work – patches, repairs and changes.

Enable   and start the instance.

$ srvctl   enable instance –db <db_name> -instance <instance_name>
  $ srvctl start instance –db <db_name>
-instance <instance_name>

Enable   and start the service back.  Check that   the service is up and running.

$ srvctl   enable service –db <db_name>
-service <service_name>
-instance   <instance_name>

$ srvctl   start service –db <db_name>
-service <service_name>
-instance   <instance_name>

The FAN   UP event for the service informs the connection pool that a new instance is   available for use, allowing sessions to be created on this instance at the   next request submission.  Automatic   rebalancing of sessions starts.

The following figure shows the distribution of connections for a service across two RAC instances before and after Planned Downtime.  Notice that the connection workload moves from fifty-fifty across both instances to hundred-zero.  In other words, RAC_INST_1 can be taken down for maintenance without any impact on the business operation.

Unplanned Outages

The configuration is the same for planned and unplanned outages.

There are several differences when an unplanned outage occurs.

  • A component at the database server may fail making all services unavailable on the instances running at that node.  There is not stop or disable on the services because they have failed.
  • The FAN unplanned DOWN event (reason=FAILURE) is delivered to the mid-tier.
  • For an unplanned event, all sessions are closed immediately preventing the application from hanging on TCP/IP timeouts.  Existing connections on other instances remain usable, and new connections are opened to these instances as needed.
  • There is no graceful draining of connections.  For those applications using services that are configured to use Application Continuity, active sessions are restored on a surviving instance and recovered by replaying the operations, masking the outage from applications.  If not protected by Application Continuity, any sessions in active communication with the instance will receive a SQLException.

Tuesday Sep 01, 2015

Active GridLink URLs

Active GridLink (AGL) is the data source type that provides connectivity between WebLogic Server and an Oracle Database service, which may include one or more Oracle RAC clusters or DataGuard sites.  As the supported topologies grow to include additional features like Global Database Services (GDS) and new features are added to the Oracle networking and database support, the complexity of the URL to access this has also gotten more complex. There are lots of examples in the documentation.  This is a short article that summarizes patterns for defining the URL string for use with AGL.

It should be obvious but let me start by saying AGL only works with the Oracle Thin Driver.

AGL data sources only support long format JDBC URLs. The supported long format pattern is basically the following (there are lots of additional properties, some of which are described below).


If not using SCAN, then the ADDRESS_LIST would have one or more ADDRESS attributes with HOST/PORT pairs. It's recommended to use SCAN if possible and it's recommended to use VIP addresses to avoid TCP/IP hangs.

Easy Connect (short) format URLs are not supported for AGL data sources. The following is an example of a Easy Connect URL pattern that is not supported for use with AGL data sources:


General recommendations for the URL are as follows.

- Use a single DESCRIPTION.  Avoid a DESCRIPTION_LIST to avoid connection delays.

- Use one ADDRESS_LIST per RAC cluster or DataGuard database.

- Put RETRY_COUNT, RETRY_DELAY, CONNECT_TIMEOUT at the DESCRIPTION level so that all ADDRESS_LIST entries use the same value. 

- RETRY_DELAY specifies the delay, in seconds, between the connection retries.  It is new in the release.

- RETRY_COUNT is used to specify the number of times an ADDRESS list is traversed before the connection attempt is terminated. The default value is 0.  When using SCAN listeners with FAILOVER = on, setting the RETRY_COUNT parameter to 2 means the three SCAN IP addresses are traversed three times each, such that there are nine connect attempts (3 * 3).

- CONNECT_TIMEOUT is used to specify the overall time used to complete the Oracle Net connect.  Set CONNECT_TIMEOUT=90 or higher to prevent logon storms.   Through the JDBC driver, CONNECT_TIMEOUT is also used for the TCP/IP connection timeout for each address in the URL.  This second usage is preferred to be shorter and eventually a separate TRANSPORT_CONNECT_TIMEOUT will be introduced.  Do not set the oracle.net.CONNECT_TIMEOUT driver property on the datasource because it is overridden by the URL property.

- The service name should be a configured application service, not a PDB or administration service.

- Specify LOAD_BALANCE=on per address list to balance the SCAN addresses.

Using Orachk to Clean Up Concrete Classes for Application Continuity

As I described in the blog Part 2 - 12c Database and WLS - Application continuity, Application Continuity (AC) is a great feature for avoiding errors to the user with minimal changes to the application and configuration. Getting rid of any references to Oracle concrete classes is the first step.

Oracle has a utility program that you can download from MOS to validate various hardware, operating system, and software attributes associated with the Oracle database and more (it’s growing). The program name is orachk. The latest version is and starting in this version, there are some checks available for applications running with AC.

There is enough documentation about getting started with orachk so I’ll just say to download and unzip the file. The AC checking is part of a larger framework that will have additional analysis in future versions. This article focuses on the analysis for Oracle concrete classes in the application code.

AC is unable to replay transactions that use oracle.sql deprecated concrete classes of the form ARRAY, BFILE, BLOB, CLOB, NCLOB, OPAQUE, REF, or STRUCT as a variable type, a cast, the return type of a method, or calling a constructor. See New Jdbc Interfaces for Oracle types (Doc ID 1364193.1) for further information about concrete classes. They must be modified for AC to work with the application. See Using API Extensions for Oracle JDBC Types for many examples of using the newer Oracle JDBC types in place of the older Oracle concrete types.

There are three values that control the AC checking (called acchk in orachk) for Oracle concrete classes. They can be set either on the command line or via shell environment variable (or mixed). They are the following.

Command Line Argument

Shell Environment Variable


–asmhome jarfilename  


This must point to a version of asm-all-5.0.3.jar that you download from http://asm.ow2.org/.

-javahome JDK8dirname


This must point to the JAVA_HOME directory for a JDK8 installation.

-appjar dirname


To analyze the application code for references to Oracle concrete classes like oracle.sql.BLOB, this must point to the parent directory name for the code. The program will analyze .class files, and recursively .jar files and directories. If you have J2EE .ear or .war files, you must recursively explode these into a directory structure with .class files exposed.

This test works with software classes compiled for Oracle JDBC 11 or 12.

When you run the AC checking, the additional checking about database server, etc. is turned off. It would be common to run the concrete class checking on the mid-tier to analyze software that accesses the Oracle driver.

I chose some old QA test classes that I knew had some bad usage of concrete classes and ran the test on a small subset for illustration purposes. The command line was the following.

$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome /tmp/jdk1.8.0_40 -appjar /tmp/appdir

This is a screen shot of the report details. There is additional information reported about the machine, OS, database, timings, etc.

From this test run, I can see that my one test class has five references to STRUCT that need to be changed to java.sql.Struct or oracle.jdbc.OracleStruct.

Note that WLS programmers have been using the weblogic.jdbc.vendor.oracle.* interfaces for over a decade to allow for wrapping Oracle concrete classes and this AC analysis doesn’t pick that up (there are five weblogic.jdbc.vendor.oracle.* interfaces that correspond to concrete classes). These should be removed as well. For example, trying to run with this ORACLE extension API and the WLS wrapper

import weblogic.jdbc.vendor.oracle.OracleThinBlob;

OracleThinBlob blob = (OracleThinBlob)rs.getBlob(2);
java.io.OutputStream os = blob.getBinaryOutputStream();

on a Blob column using the normal driver works but using the replay driver yields

java.lang.ClassCastException: weblogic.jdbc.wrapper.Blob_oracle_jdbc_proxy_oracle
$1OracleBlob$$$Proxy cannot be cast to weblogic.jdbc.vendor.oracle.OracleThinBlob

It must be changed to use the standard JDBC API

java.sql.Blob blob = rs.getBlob(2);
java.io.OutputStream os = blob.setBinaryStream(1);

So it’s time to remove references to the deprecated Oracle and WebLogic classes and preferably migrate to the standard JDBC API’s or at least the new Oracle interfaces. This will clean up the code and get it ready to take advantage of Application Continuity in the Oracle database.

Thursday Aug 27, 2015

New Partner Solutions on WebLogic and the Oracle Database Appliance

With the latest release of WebLogic on ODA, which now supports the X5-2 hardware, we have come to a new chapter. Oracle partners around the world have been developing customized solutions using WebLogic on ODA for years now. Many of them started with the wizard-driven templates produced by the Oracle WebLogic engineering team, and then went on to design their own customized solutions by expanding on and embellishing these templates for their customers' unique needs.

It became obvious that, to best support our existing users, and to give new customers more immediate access to the tools and resources they need for success, we would formalize this direction by shifting resources to enable Oracle WebLogic 12c specialized partners to rapidly gain expertise and traction in this arena.

To this end, we are publishing a new whitepaper how-to guide, Running Middleware Applications on ODA Machines, that can be used by partners or end users to speedily deploy a highly available platform on which to run Java applications. We are also announcing that this latest release of the WebLogic templates is also our final release. However, we will continue to encourage and support customer and partner led development efforts.

Attend a webinar on September 4th at 10am PT, to better understand what is in the latest release of WebLogic on ODA, and to hear directly from one of our expert partners on some of the solutions currently offered on ODA. http://ouweb.webex.com, Session Number: 599 716 170. Dial in: 877-814-3159 or 706-634-9616; Passcode: 210550.

Thursday Aug 13, 2015

WebLogic Server 12.1.3 Developer Zip Update 3

WebLogic Server 12.1.3 Developer Zip Update 3 has just been posted to OTN for download. 

Update 3 contains the same set of bugs fixes in the WebLogic Server Patch Set Update, providing developers who use the developer zip distribution with a version that corresponds to the latest version of WebLogic Server 12.1.3 used for production.

Download page:


The README file for Update 3 provides details of the updates:


Wednesday Jul 29, 2015

WebLogic Update @ Voxxed Days Istanbul

It's relatively rare Java focused conferences have clearly WebLogic centric sessions. This is understandable as conference organizers must carefully balance between education, vendor-neutrality, sharing useful information and outright sales pitches. The distinction is very tenuous and historically frequently abused at Java conferences. As a result Java conference organizers (and attendees) often choose to err on the side of caution and avoid content focused on commercial products (note that while WebLogic is beyond a doubt a commercially licensed product developers can use it freely on their own local machines with an OTN license). An unfortunate side effect of this problem is that many developers remain woefully unaware of the changes happening in mission critical bits of industry infrastructure such as WebLogic. The exception to this unfortunate situation is events like Oracle OpenWorld and other Oracle technology centric conferences where WebLogic is far better represented.

For these reasons it was a breadth of fresh air to be able to deliver a brief WebLogic centric session at Voxxed Days Istanbul 2015. I am so grateful to the organizers for lending me the benefit of the doubt and recognizing the distinction between selling and informing current/prospective users about important technological changes that can help their organizations. Titled "What's New in WebLogic 12.1.3 and Beyond", the talk essentially covers the very important hard work that we have already done in WebLogic 12.1.3 including supporting some of the most critical Java EE 7 APIs as well as the fundamental changes coming soon in WebLogic 12.2.1 including full Java EE 7 platform support. Below is the slide deck for the talk (click here if you can't see the embedded slide deck.):

If you have not yet taken a look at WebLogic 12.1.3 and the road map for 12.2.1, the deck should offer a quick way to do so. Here is the abstract for the talk to give you better context:

WebLogic 12.1.3 was released about a year ago. It brings a large set of changes including support for some key new Java EE 7 APIs such as WebSocket, JAX-RS 2, JSON-P and JPA 2.1, support for Java SE 8, WebSocket fallback support, support for Server-Sent Events (SSE), improved Maven support, enhanced REST administration support, Oracle Database 12c driver support and much, much more. In this session we will take a detailed tour of these features. In addition we will also cover updated WebLogic support in the Oracle Cloud, the new Oracle public Maven repository, using WebLogic with Arquillian for testing and well as official Docker support for WebLogic. Towards the end of the session we will discuss what's coming in WebLogic 12.2.1 this year including full support for Java EE 7, multi-tenancy and more.

Besides the brief WebLogic talk I also covered Java EE 7 and Java EE 8 at Voxxed Days Istanbul as well as the Istanbul and Ankara JUG. More details of the event are posted on my personal blog.

Friday Jul 17, 2015

Accessing WebLogic Logs via REST

One of the most significant changes in the WebLogic 12.1.3 release is improvements in the REST management interface. Oracle ACE Director and WebLogic expert Dr. Frank Munz does a very nice job summarizing the changes on his blog. The REST management capability is really quite a nice addition to the existing DevOps oriented capabilities such as WLST and of course the admin console. One of the very interesting things you can do via the REST management interface in WebLogic 12.1.3 is easily access all WebLogic logs. Dr. Frank Munz explains nicely step by step how to do this via another excellent blog entry well worth a read.

The best way to learn the details of the REST management capabilities is of course always the WebLogic documentation.

Tuesday Jun 30, 2015

Oracle Cloud Application Foundation Innovation Awards Now Open for Nominations!

Is your organization using Oracle Cloud Application Foundation that includes Oracle WebLogic Server, Oracle Coherence and Oracle Tuxedo to deliver unique business value? The Innovation Awards awards honor our customers and partners for their cutting-edge solutions. Winners are selected based on the uniqueness of their business case, business benefits, level of impact relative to the size of the organization, complexity and magnitude of implementation, and the originality of architecture.

The 2015 awards will be presented during Oracle OpenWorld 2015, October 26-29, in San Francisco.

Submit your nomination for WebLogic/Coherence/Tuxedo by July 31!

Award winners receive:

  • Oracle Fusion Middleware Innovation Award for WebLogic trophy
  • One free pass to Oracle OpenWorld 2015
  • Priority consideration for placement in Profit magazine, Oracle Magazine, or other Oracle publications and press releases
  • Oracle Fusion Middleware Innovation logo for inclusion on your own website and/or press release   

All nominees receive consideration for:

  • Participating in OpenWorld panels and speaking opportunities
  • Featured Customer Success Story on Oracle.com
  • Placement in Profit magazine and/or Oracle Magazine
  • Placement in an Oracle press release or Oracle Fusion Middleware podcast
Nomination deadline: 5:00 p.m. PT July 31, 2015
All nominated solutions should be in production or in active pilot phase

For additional information, please email Innovation-Middleware_us@oracle.com

Thursday Jun 18, 2015

Managing Logs in WebLogic

Logging is your first line of defense in terms administering, debugging and monitoring any part of the data center and especially the application server. WebLogic generates a number of very helpful log files for that reason. In addition WebLogic also provides ways to robustly manage these log files in terms of tuning things like log rotation and filtering. Ahmed Aboulnaga introduces some of these capabilities in a recent article on OTech Magazine (his article is mostly focused on the admin console).

The most detailed and up-to-date way to learn about WebLogic logging is always of course the WebLogic documentation. For example a couple of important logging aspects the article does not get into include configuring the logs themselves as well as easily viewing the logs through the WebLogic console.

Tuesday Jun 09, 2015

Your Spring application takes longer to deploy? Think again!

Uday Joshi of the WebLogic Team was recently asked to understand why a large Spring based application took longer to deploy on WebLogic than on Tomcat. And to do that, Uday only had one constraint, i.e. he was not given access to that Spring application! The only thing Uday had at his disposal was the deployment-time thread dumps of that application, nothing else.

In this detailed article, Uday describes how he mimicked the 'suspicious' application to understand what was going on. He also shares some of his findings and some recommendations like using filtering classloader. This article is based on a large Spring application but those recommendations also apply to any large application. 

Friday Jun 05, 2015

A Gentle Introduction to the WebLogic Diagnostic Framework (WLDF)

The WebLogic Diagnostic Framework (WLDF) is a powerful feature that has been around since WebLogic 9. It is an extremely robust way of live monitoring and diagnostics for the server, the underlying JVM, deployed applications and configured resources. Few if any other Java application servers can match the capabilities offered by WLDF. If you using WebLogic in production and don't know about WLDF, you are doing yourself a serious disservice.

Because of the power and flexibility offered by WLDF, it is not trivial to pick up and for some can be daunting. Fortunately Mike Croft of Oracle partner C2B2 consulting can help us out. He wrote up a very nice series of blog entries as a gentle introduction to WLDF. He provides a high level overview and discusses watches, notifications and the monitoring dashboard. The definitive way to learn about WLDF is of course always the latest WebLogic documentation :-).

Friday May 29, 2015

Your Opinion Wanted - What Would You Like to See in OTN Virtual Summits?

If you don't know about the OTN Virtual Technology Summit yet, you are doing yourself a serious disfavor. The summit is a set of free online events covering various technical topics such as Java SE and Java EE but also WebLogic, Coherence, Middleware, Database and so on. Each topic is presented by a subject matter expert coming either from Oracle or from the community (Java Champions, Oracle ACEs and so on). During each session a live chat lets participants ask questions and clarifications on the presented subject. The summit is held four time a year!

Now you can chime in to tell us exactly what you would like to see in terms of middleware content in the summit. Of course we not-so-secretly hope you will ask for more Java EE, WebLogic or Coherence content! You can voice your opinion at any time using this public page on the Oracle Community site. Beyond simply asking for a topic, you are also most welcome to nominate yourself or someone else you know as a speaker. It's a great way of sharing your knowledge and getting some recognition, so don't be shy!

Monday May 18, 2015

WLS Tip: Getting started with Arquillian on WebLogic Server

Arquillian is a popular open-source testing framework for Java EE containers. In this short video, Phil Zampino of the Oracle WebLogic Server Development Team shows how to get started with Arquillian to test applications running in WebLogic Server. For a more details on using Arquillian with WebLogic, you can then check this article.

For your convenience, you can also download this archive that contains the test application and the configuration files (pom.xml & arquillian.xml) used in the video.

Wednesday Apr 15, 2015

WLS Tip: Installing WebLogic with Chef

Chef is a popular open source infrastructure automation framework that has been popularized with the whole DevOps movement. In a nutshell, Chef has the notion of Recipe and Cookbook. A Recipe is written using a Ruby based DSL to describe how to install and configure software(s) on a host. And as the name suggest, a Cookbook is a collection of related Recipes.

This article explains how to create a simple WebLogic Cluster (on a VM) with two Managed Servers using Chef. The Cookbook described in the article can obviously be used as the basis for more advanced scenarios involving WebLogic.


The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« October 2015