Friday, August 31, 2012

Which JVM?

When you report java.lang.OutOfMemoryError: Java heap space, you need to tell people which JVM has thrown the exception.  Sometimes this can be obvious and sometimes it isn't (see below).

An OutOfMemoryError does not necessarily imply a memory leak. The issue might simply be a configuration issue, for example if the specified heap size (or the default size if not specified) is insufficient for the application[1].  In that case, you need to figure out which configuration file to modify.

jps Command

You can use jps (Java Virtual Machine Process Status Tool) to list all local VM identifiers of instrumented HotSpot Java Virtual Machines (JVMs) on the target Linux system.  For example, on my system, it lists:

$ jps 
17291 Server
17468 Jps
7883 Launcher

This list includes one Integrated WebLogic Server (i.e., Server) and one JDeveloper (i.e., Launcher). Note that JDeveloper and Integrated WLS use their own JVM's. So, if you're running Integrated WLS from JDeveloper, you need to know which JVM has thrown the OutOfMemoryError exception.

Configuration Files

Each application uses its own configuration file to start its JVM and you need to know where to find it.

For example, to change heap space sizes, you can modify those parameters in:
  • JDeveloper
    • $JDEV_HOME/jdev/bin/jdev.conf
    • or 'which jdev' and find its containing directory; jdev.conf should be located in the same directory 
    • Note that jdev.conf includes ide.conf which contains the following configurations:
      • AddVMOption  -Xmx640M
      • AddVMOption  -Xms128M
  • WebLogic Server
    • You have two options:
      • Modify MEM_ARGS in the
      • $setenv USER_MEM_ARGS "-Xms512m -Xmx1024m -XX:MaxPermSize=1024m -XX:CompileThreshold=8000"
        • This will override the settings from WLS scripts as shown below:
          • if [ "${USER_MEM_ARGS}" != "" ] ; then
            export MEM_ARGS
    • If this is Integrated WLS, your script folder is located under:
      • ../system11.
      • On JDev 12c, the heap size is set by the following line (which is embedded in[5]
        • set SERVER_MEM_ARGS_64=-Xms1024m -Xmx3072m
          • You can trace the settings starting from, to, to, and finally to
  • Eclipse
    • /eclipse.ini

Project Properties

Here is another case which requires the change of project properties in JDeveloper:
  • Scenario:
    • JDeveloper is used to deploy "server-setup-seed-deploy-test" target with "Run Ant Target" and it threw "java.lang.OutOfMemoryError: PermGen space" exception.[2]
  • Solution:
    • In Jdev window, right click the project file >  Project Properties > Ant > Process > Java Options:
      • -Xms512m -Xmx1024m -XX:PermSize=512m -XX:MaxPermSize=1024m
    • Note that a new JVM is launched for the Ant process and it uses the above settings.


Thursday, August 30, 2012

Java Performance Tips

Every little things add up. The overall performance of an application depends on the individual performance of its components. Here we list some of the Java programming tips to help your application perform:

Programming Tips Why and How
Avoid creating duplicate objects Why:
  • Less objects less GC.
  • Application with smaller footprint performs better.
  • Reuse a single object instead of creating a new functionally equivalent object each time it's needed.
    • (Do)
      • String s = "No longer silly";
    • (Don't)
      • String s = new String("silly");
  • Use static factory methods in preference to constructors on immutable classes that provide both.
  • Reuse mutable objects that are never modified once their values have been computed (within a static initializer).
Avoid circular references Why:
  • Groups of mutually referencing objects which are not directly referenced by other objects and are unreachable can thus become permanently resident.
  • You can use strong references for "parent-to-child" references, and weak references for "child-to-parent" references, thus avoiding cycles.
Caching frequently-used data or objects Why:
  • One of the canonical performance-related use cases for Java is to supply a middle tier that caches data from back-end database resources.
    • (Warning) Like all cases where objects are reused, there is a potential performance downside: if the cache consumes too much memory, it will cause GC pressure.
  • Code should use a PreparedStatement rather than a Statement for its JDBC calls.
  • Reuse JDBC connections because connections to a database are time-consuming to create.
Use the == operator instead of the equals(Object) method Why:
  • == operator performs better.
    • For example, for String comparison, the equals( ) method compares the characters inside a String object. The == operator compares two object references to see whether they refer to the same instance.
  • a.equals(b) if and only if a == b
    • For example, use static factory method to return the same object from repeated invocations.
Eliminate obsolete object references Why:
  • Reduced performance with more garbage collector activity
  • Reduced performance with increased memory footprint
  • Null out references once they become obsolete
  • (Do)
    • public Object pop() {
       if (size == 0)
         throw new EmptyStackException(;
       Object result = elements[--size];
       elements[size] == null;  // Eliminate obsolete reference
       return result;
  • (Don't)
    • public Object pop(){
       if (size == 0)
         throw new EmptyStackException(;
       return elements[--size];
Avoid finalizers Why:
  • Objects waiting for fnalization have to be kept track of separately by the garbage collector. 
  • There is also call overhead when the finalize method is invoked
  • Finalizers are unsafe in that they can resurrect objects and interfere with the GC.

Avoid reference objects Why:

  • As with fnalizers, the garbage collector has to treat soft, weak, and phantom references specially. 
  • Although all of these can provide great aid in, for example, simplifying a cache implementation, too many live Reference objects will make the garbage collector run slower. 
  • A Reference object is usually a magnitude more expensive than a normal object (strong reference) to bookkeep.
  • To find out the number of references and the time it takes to process them in HotSpot, add the following JVM option:
    • -XX:+PrintReferenceGC
Avoid object pooling Why:
  • Object pooling contributes both to more live data and to longer object life spans.
  • Note that large amounts of live data is a GC bottleneck and the GC is optimized to handle many objects with short life spans.
  • Also, allocating fresh objects instead of keeping old objects alive, will most likely  be more beneficial to cache locality.
  • However, performance in an environment with many large objects, for example large arrays, may occasionally benefit from object pooling.
Choose good algorithms and data structures Why:
  • Consider a queue implementation in the form of a linked list.
    • Even if your program never iterates over the entire linked list, the garbage collector still has to.
    • Bad cache locality can ensue because payloads or element wrappers aren't guaranteed to be stored next to each other in memory. This will cause long pause times as, if the object pointers are spread over a very large heap area, a garbage collector would repeatedly miss the cache while doing pointer chasing during its mark phase.
Avoid System.gc  Why:
  • There is no guarantee from the Java language specifcation that calling System.gc will do anything at all. But if it does, it probably does more than you want or doesn't do the same thing every time you call it. 
Avoid too many threads Why:
  • The number of context switches grows proportionally to the number of fairly scheduled threads, and there may also be hidden overhead here.
    • For example, a native thread context on a system such as Intel IA-64 processor is on the order of several KB.
Avoid contented locks Why:
  • Contended locks are bottlenecks, as their presence means that several threads want to access the same resource or execute the same piece of code at the same time. 
Avoid unnecessary exceptions Why:
  • Handling exceptions takes time and interrupts normal program flow. 
  • Authors[1] have seen cases with customer applications throwing tens of thousands of unnecessary NullPointerExceptions every second, as part of normal control fow. Once this behavior was rectifed, performance gains of an order of magnitude were achieved.

Avoid large objects Why:
  • Large objects sometimes have to be allocated directly on the heap and not in thread local areas (TLA).
    • Large objects on the heap are bad in that they contribute to fragmentation more quickly.
  • Large object allocation in VMs (for example, in JRockit) also contributes to overhead because it may require taking a global heap lock on allocation.
  • An overuse of large objects leads to full heap compaction being done too frequently, which is very disruptive and requires stopping the world for large amounts of time.

Tuning Guidelines

As stated in [6], here are the guidelines for tuning your applications:
You should take an overall system approach to ensure that you cover all facets of the environment in which the application runs. The overall system approach begins with the external environment and continues drilling down into all parts of the system and application. Taking a broad approach and tuning the overall environment ensures that the application will perform well and that system performance can meet all of your requirements.


  1. Oracle JRockit
  2. Effective Java by Joshua Bloch
  3. hashCode() and equals() in Java
  4. HotSpot VM Performance Tuning Tips
  5. Java Performance by Charlie Hunt, Binu John, David Dagastine
  6. Professional Oracle WebLogic Server by Robert Patrick, Gregory Nyberg, and Philip Aston
  7. Sun Performance and Tuning: Java and the Internet by Adrian Cockroft and Richard Pettit
  8. Concurrent Programming in Java: Design Principles and Patterns by Doug Lea
  9. Capacity Planning for Web Performance: Metrics, Models, and Methods by Daniel A. MenascĂ© and Virgilio A.F. Almeida
  10. Big-O complexities of common algorithms (Cheat Sheet)

Saturday, August 25, 2012

Understanding JVM Thread States

To investigate CPU issues in Java applications, one approach is to diagnose monitor locks and thread activities[1].

In this article, we will show you:
  • How to generate thread dumps on different VMs
  • What to know about thread states

JVM Thread States

A thread can be in only one state at a given point in time. These states are virtual machine states which do not reflect any operating system thread states. As an example, here shows different threads in different states on a HotSpot VM:

$ cat thread.tmp | grep "java.lang.Thread.State" | sort | uniq -c
      3    java.lang.Thread.State: BLOCKED (on object monitor)
     18    java.lang.Thread.State: RUNNABLE
      6    java.lang.Thread.State: TIMED_WAITING (on object monitor)
      2    java.lang.Thread.State: TIMED_WAITING (sleeping)
     13    java.lang.Thread.State: WAITING (on object monitor)
      3    java.lang.Thread.State: WAITING (parking)

Below we describe some of the thread states that can be found in a thread dump:
  • NEW - this state represents a new thread which is not yet started.
  • RUNNABLE - this state represents a thread which is executing in the underlying JVM. Here executing in JVM doesn't mean that the thread is always executing in the OS as well - it may wait for a resource from the Operating system like the processor while being in this state.
  • BLOCKED (on object monitor)- this state represents a thread which has been blocked and is waiting for a moniotor to enter/re-enter a synchronized block/method. A thread gets into this state after calling Object.wait method.
  • WAITING - this state represnts a thread in the waiting state and this wait is over only when some other thread performs some appropriate action. A thread can get into this state either by calling - Object.wait (without timeout), Thread.join (without timeout), or LockSupport.park methods.
  • TIMED_WAITING - this state represents a thread which is required to wait at max for a specified time limit. A thread can get into this state by calling either of these methods: Thread.sleep, Object.wait (with timeout specified), Thread.join (with timeout specified), LockSupport.parkNanos, LockSupport.parkUntil
  • TERMINATED - this state reprents a thread which has completed its execution either by returning from the run() method after completing the execution OR by throwing an exception which propagated from the run() method and hence caused the termination of the thread.
  • WAITING (parking)- it means a wait state after being parked. A thread can suspend its execution until permit is available (or thread is interrupted, or timeout expired, etc) by calling park(). You can give permit to a thread by calling unpark(). When permit is available, the parked thread consumes it and exits a park() method. Unlike Semaphore's permits, permits of LockSupport are associated with threads (i.e. permit is given to a particular thread) and doesn't accumulate (i.e. there can be only one permit per thread, when thread consumes the permit, it disappears).

  1. It's hard to investigate any CPU issue just from one thread dump. So, you need to prepare a series of thread dumps for investigation. For an example of analyzing hanging problems, see [9].
  2. The above thread state information is for HotSpot.  To understand JRockit's thread dump contents, read [4].

Generating Thread Dumps in HotSpot

$jcmd 15679 Thread.print >thread.tmp

where 15679 is the process ID. For example, it will print the following messages:

2012-08-24 11:27:27
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.0-b21-internal mixed mode):

"Attach Listener" daemon prio=10 tid=0x000000000528e000 nid=0x4653 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-29" daemon prio=10 tid=0x00002aaab9447000 nid=0x3fe3 runnable [0x000000004408b000]
   java.lang.Thread.State: RUNNABLE
        at Method)
        - locked <0x00000000f5ae4738> (a

Generating Thread Dumps in JRockit[4]

$jrcmd 1286 print_threads
where 1286 is the process ID. For example, it will print the following messages:


===== FULL THREAD DUMP ===============
Thu Aug 23 17:36:30 2012
Oracle JRockit(R) R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64

"Main Thread" id=1 idx=0x4 tid=1287 prio=5 alive, waiting, native_blocked
    -- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0xe48b4598[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at java/lang/Object.wait(
    at weblogic/t3/srvr/T3Srvr.waitForDeath(
    ^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0xe48b4598[fat lock]
    at weblogic/t3/srvr/
    at weblogic/Server.main(
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

"(Signal Handler)" id=2 idx=0x8 tid=1288 prio=5 alive, native_blocked, daemon

"(OC Main Thread)" id=3 idx=0xc tid=1289 prio=5 alive, native_waiting, daemon


  1. Understanding Threads and Locks
  2. Thread States Diagram
  3. Useful tool: jrcmd
  4. Using Thread Dumps
  5. Understanding a Java thread dump
  6. Fun with JStack 
  7. Java 2 Platform, Standard Edition 5.0 "Trouobingshooting and Diagnostic Guide"
  8. HotSpot VM Performance Tuning Tips
  9. Analyze Hanging Programs Using Java Thread Traces (XML and More)

Thursday, August 23, 2012

How Can I Tell if My System Is Using Hyper-Threading Technology?

New microarchitecture poses challenges for traditional system monitoring tools in terms of how CPU utilizations should be interpreted when logical or virtual processors are exposed to operating systems as if they were physical processors.

Whether it's a physical processor, a hyperthreaded logical processor, or a core, they all appear as a CPU to the operating system, which imposes challenges for interpreting the log data you collect with the processor performance counter.

What's Hyper-Threading?

Intel® Hyper-Threading Technology (Intel® HT Technology) delivers two processing threads per physical core. It is a form of simultaneous multi-threading that takes advantage of super scalar architecture (multiple instructions operating on separate data in parallel). They appear to the OS as two processors, thus the OS can schedule two processes at once. In addition two or more processes can use the same resources. If one process fails then the resources can be readily re-allocated.

Many of the desktop and server platforms that ship with Intel processors include hyper-threading support.  This means that you must have a processor, chipset, operating system, and BIOS that all support the technology.  Most of these platforms will allow you to enable or disable Hyper-Threading Technology as a BIOS option (it should be enabled by default).

You can view your CPU information using the Task Manager in Windows, and /proc/cpuinfo in Linux. If you have a supported platform and Hyper-Threading is enabled, you should see twice the number of CPUs as you have physical cores in your platform.


Using our system (i.e., Westmere-EP) as an example, it is a dual-processor Xeon® 5650 series server.  Then you should see 24 logical CPUs (24 hardware threads running on 6 physical cores, 2 threads per core) from /proc/cpuinfo.

$ cat /proc/cpuinfo | egrep "physical\ id" | sort | uniq -c
     12 physical id     : 0
     12 physical id     : 1
The above shows that our system has two physical processors.  We know each processor has 6 cores.  Because hyper-threading was enabled, we see 12 logical CPUs per processor as shown on the lines.


  1. Intel® Hyper-Threading Technology: Your Questions Answered
  2. Intel® Xeon® Processor X5650
  3. Westmere-EP

Monday, August 20, 2012

JRockit Version Information

There are at least three version  numbers of interest for each JRockit release:
  1. JRockit JVM version
  2. JDK version
  3. Mission Control version

JDK Version and JVM Version

To obtain the version number of the JDK and JVM, you execute the following command from the prompt:
  • java -version
For example, this is displayed from my system:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 
Oracle JRockit(R) (build R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64, compiled mode)

Each version of the JRockit JVM is built for several different JDKs. Oracle JRockit R28 supports the following Java versions:
  • J2SE 5.0
  • Java SE 6
Ensure that your application complies with the Java specification corresponding to the Oracle JRockit release that you use.

You can find two pieces of information from the above output:
  1. JDK version
    • "1.6.0_24" is the JDK version being bundled with the JVM
    • In other words, Java 1.6 is supported and it is bundled with the JDK classes from update 24-b07.
  2. JRockit JVM version
    • R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64
      • Version number:  R28.1.3
      • Build number:  11
      • Change number:  141760
      • Date and Time: 20110301-1432 (in  compact ISO 8601 format)
      • JVM is built for:
        • OS: Linux
        • CPU Architecture: x86_64

Mission Control Version

The JRockit Mission Control tools suite includes tools to monitor, manage, profile, and eliminate memory leaks in your Java application without introducing the performance overhead normally associated with tools of this type.

The version number for JRockit Mission Control can be gathered from command prompt by executing:
  • jrmc -version

The output should look like this:

Oracle JRockit(R) Mission Control(TM) 4.0 (for JRockit R28.0.0)
  java.vm.version = R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64
  build = M4.0.1-19
  chno = 134472
  jrmc.fullversion = 4.0.1
  jrmc.version = 4.0
  jrockit.version = R28.0.0
  year = 2010

The frst line tells us what version of Mission Control this is and what version of JRockit it was created for. The java.vm.version line tells us what JVM Mission Control is actually running on.


  1. Oracle JRockit--The Defnitive Guide
  2. J2SE 5.0
  3. Java SE 6
  4. Oracle® JRockit Installation and Upgrade Guide Release R28
  5. JRockit Mission Control
  6. Oracle® JRockit Command-Line Reference Release R28

Sunday, August 19, 2012

Book Review: "Getting Started with Oracle Data Integrator 11g: A Hands-On Tutorial"

In July 2010, Oracle Data Integrator 11gR1 (or ODI) was made available to the marketplace.  It has roots from the Oracle acquisition of Sunopsis in October 2006.  This product is important because:
  • It is Oracle's strategic data integration platform 
  • It is the first version of ODI architected, designed, and implemented as part of Oracle

Challenges of Data Integration Tasks

Data integration tasks include loading, enrichment, quality control and transformation of data.  The challenges of its tasks include:

  • Data Complexity
    • Data is stored in disparate applications, databases, files, operating systems, and in incompatible formats.
    • Large volume of data has to be exchanged
  • Transformation Complexity
    • Complex transformations needed are beyond the capabilities of the SQL languages.
  • Operational Complexity
    • Systems with data of heterogeneous types flowing across different platforms are not easy to design or maintain.  In addition, data security, integrity and auditing requirements add more complexity.

Oracle Data Integrator

Facing such challenges, ODI has provided a unique solution.  This is where its ELT architecture (Extract-Load-Transform) comes into play. The concept with ELT is that instead of extracting the data from a source, transforming it with a dedicated platform, and then loading into the target database, you will extract from the source, load into the target, then transform into the target database, leveraging SQL for the transformations.
To some extent, ETL and ELT are marketing acronyms. When you look at ODI for instance, it can perform transformations on the source side as well as on the target side. You can also dedicate some database or schema for the staging and transformation of your data, and can have something more similar to an ETL architecture. Similarly, some ETL tools all have the ability to generate SQL code and to push some transformations at the database level.

However, the key differentiators of ODI are as follows:
  • Its ability to dynamically manage a staging area (location, content, automatic management of table alterations)
  • Its ability to generate code on source and target systems alike, in the same transformation
  • Its ability to generate native SQL for any database on the market
  • Its ability to generate DML and DDL, and to orchestrate sequences of operations on the heterogeneous systems

The Book

This book has done a great job of introducing ODI at both conceptual and operational levels.  It covers how ODI leverages next generation Extract-Load-Transformation technology to deliver extreme performance in enabling state of the art solutions that help deliver rich analytics and superior business intelligence in modern data warehousing environments.

At conceptual level, it has discussed how ODI can deal with heterogeneous datatypes with ease and efficiency.  For example, it introduces the concepts of:
  • Abstraction
    • ODI models and data integration objects are abstracted to be independent of the physical data server type (database, file, JMS queues and topics, and so on), so they will have a common look and feel despite having dramatically different physical representations. 
  • Decoupling
    • Logical schema names are used to decouple us from any specific operational environment while contexts are used to link the physical and logical representations.
  • Declarative Design
    • The definition of the transformation logic is isolated from the definition of the data movement and integration logic.
      • Separating the two allows developers to focus more on the moving parts (the transformations) than on the stable parts (the integration strategy).
    • Variables are used to store dynamic information.
  • Delegating and distributing processing
    • Agents are used as orchestrators for the data movement and transformations.

Using these design patterns, ODI allows:
  • Integration strategies be reused
  • Heterogeneity of data server types be encapsulated via models and other integration objects
  • Life management of development, test, or production environments be easily maintained

For operational details, the largest part of the book is a set of hands-on step-by-step tutorials that build a non-trivial Order Processing solution that you can run, test, monitor, and manage. It has highlighted the key capabilities of the product in relation to data integration tasks (loading, enrichment, quality, and transformation) and the productivity achieved by being able to do so much work with heterogeneous datatypes while writing so little SQL.


  1. Getting Started with Oracle Data Integrator 11g: A Hands-On Tutorial
  2. Oracle Fusion Middleware Supported System Configurations
  3. Take SOA Deployments to the Next Level with Oracle Data Integrator

Sunday, August 12, 2012

How to See a Long Command Line of a Running Process on HotSpot VM

To find the command line of a running Java process, you can use the following different approaches[1]:
  1. ps -ef | grep java
  2. cat /proc/<pid>/cmdline
  3. jps -vl | grep
However, as you may soon find out, the displayed command line got truncated in the output.  For example, using my Linux system, the maximum lengths of a command line displayed using the above approaches are:
  1. 4096
  2. 4029
  3. 1024
Unfortunately, my original command line is 7972 characters long.  So, none of the above approaches help.

jinfo & jrcmd

If you are using HotSpot VM, there is one command that can help:
  • jinfo
To run it, you provide the process ID as its argument:

$jinfo 26467
Attaching to process ID 26467, please wait...
WARNING: Hotspot VM version 23.0-b21-internal does not match with SA version 23.0-b18. You may see unexpected results.
Debugger attached successfully.
Server compiler detected.
JVM version is 23.0-b21-internal

In its standard output, it displays VM Flags at the end.

VM Flags:

-XX:MaxPermSize=512m -Xmx4g -Xms128m -verbose:class -XX:-UseCompressedStrings -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xms4096m -Xmx4096m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/u01/rup1/instance/debug -Dweblogic.Name=SalesServer_1 -Dweblogic.ProductionModeEnabled=true -Dweblogic.system.BootIdentityFile=/c1/mt/rup1/instance/domains/ -Dweblogic.nodemanager.ServiceEnabled=true -Dweblogic.Reverse

If you're using JRockit, there is a similar command that you can use:

$jrcmd  20507 command_line
Command Line: -Xmx4g -Xms128m -Xms4096m -Xmx4096m -Xgc:genpar -XX:+HeapDumpOnOutOfMemoryError...


Note that you need to make sure that the jinfo you are running is the same JVM install as what your Java program is running.  If you don't, you may see the following RuntimeException:

$ jinfo 26467
Attaching to process ID 26467, please wait...
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
Caused by: java.lang.RuntimeException: Type "nmethodBucket*", referenced in VMStructs::localHotSpotVMStructs in the remote VM, was not present in the remote VMStructs::localHotSpotVMTypes table (should have been caught in the debug build of that VM). Can not continue.
        at sun.jvm.hotspot.HotSpotTypeDataBase.lookupOrFail(
        at sun.jvm.hotspot.HotSpotTypeDataBase.readVMStructs(
        at sun.jvm.hotspot.HotSpotTypeDataBase.(
        at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(
        at sun.jvm.hotspot.bugspot.BugSpotAgent.go(
        at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(
        ... 6 more

To fix this, I have provided the full path of JDK was used to run my original Java program in the jinfo command line:
  • /c1/mt/rup1/xxxapps/HS/bin/jinfo  26467


Sunday, August 5, 2012

Book Review: "Oracle WebLogic Server 12c: First Look"

Oracle WebLogic 12c is Oracle's number one strategic Application Server.  Note that g in 11g is replaced by c in 12c where g stands for grid computing and c stands for cloud computing.  WebLogic 12c has been optimized for deployment and running on:
  • Oracle's Private Cloud, Exalogic
  • Public Cloud
  • Conventional systems
which was announced by Oracle on December 1, 2011,

This book provides readers a first look inside the new release of Oracle WebLogic 12c.

Overview of WebLogic 12c

There are over 200 new features in the new release of WebLogic 12c.  Some of the most important features include Java EE 6 and Exalogic readiness.

Oracle Exalogic Elastic Cloud is the engineered system specifically designed to provide enterprises with a foundation for secure, mission-critical private cloud.  The following diagram shows how various main components and WebLogic 12c are integrated in the Exalogic stack:

The Exalogic Elastic Cloud is a component of Oracle's Cloud Application Foundation, the company's next-generation application infrastructure. It combines the Exalogic cloud and the WebLogic Server with Tuxedo for C/C++/COBOL, Oracle's Coherence in-memory data grid, the JRockit and Hotspot Java VMs, Oracle Enterprise Manager, and the Oracle Virtual Assembly Builder.


Oracle WebLogic 12c implements the new Java EE 6 standard and supports Java SE 7.  It has also made a huge effort to make it compatible with a huge range of external systems, configurations, and so on. In almost every part, there have been major and sometimes minor updates to make the Java Application Server the most complete one.

It has a tighter integration with the latest Coherence.  The newest version of Coherence ( 3.7.*) has ActiveCache integration with WebLogic Server. It has Coherence cluster MBeans within WebLogic Server. The Node Manager is enhanced for starting/stopping Coherence cache servers from the Administration Console or doing it remotely.

WebLogic 12c also works closely with Oracle Virtual Assembly Builder (OVAB).  Oracle Virtual Assembly Builder is a tool that creates multi-tier Oracle Fusion Middleware environments as prepackaged Oracle VM templates. These packages  are called assemblies. They contain preconfigured virtual machines and a complete prepared environment which can be deployed on Exalogic on demand.

Finally, Oracle Enterprise Manager 12c can be used to mange and monitor the above-mentioned environments  It not only gathers configuration information about WebLogic Server, but also its underlying hardware and operating system.  Overall, it provides the following functionality:
  • Complete Lifecycle Management
  • Integrated Cloud Stack Management
  • Business-driven Application Management


  1. Oracle WebLogic Server 12c: First Look
  2. Oracle® Fusion Middleware Configuring Server Environments for Oracle WebLogic Server 12c Release 1 (12.1.1)
  3. Introducing the Java EE 6 Platform
  4. Oracle Enterprise Manager 12c
  5. Oracle Exalogic Elastic Cloud: A Brief Introduction
  6. Oracle® Fusion Middleware Oracle WebLogic Server Release Notes 12c Release 1 (12.1.1)
  7. WebLogic Server 12c (12.1.1.x) Certification Matrix.
  8. Oracle® Fusion Middleware What's New in Oracle WebLogic Server 12c Release 1 (12.1.1)
  9. Oracle WebLogic Server 12.1.3 Developing with WebLogic Server (Whitepaper)