Tag: JVM

Security Breach And Attack For Java Based Application Servers


Jay SenSharma

Jay SenSharma


In this article we may see an abnormal behaviors of weblogic. Which may not be necessarily a BUG but it is always to be aware of such behavior while using Weblogic. The idea behind making this page is just to make awareness among the WebLogic Admins to be alert specially when the some of these behaviors are related to WebLogic Security.

Some of the behaviors of WebLogic which may be due to inappropriate Security implementation in the Security system of WebLogic, Even if in some cases it is work as designed, Still it suggests to keep an eye on it and try to make those features more enhanced. Some of them are now fixed by the Application Server Vendor but still some need to be fixed or enhanced. The intentions here are not to point to the weak points of any Application Server but solely to make people aware about such strange or uncommon behaviors.

Any WebServer or Application Server which runs on below mentioned JVM are not safe due to the security breach. For example if you just want to hang A server then just sent the following request to the Server using any HttpClient like JMeter or any other Utility which allows you to send the Http Header of your Choice.

Once you are able to send the following Http Request Header successfully to the Java based Application/Web Server …the Server will try to parse the Http Request Header and it will Hang  while processing this request.

“GET”,”/”,headers={“Accept-Language”: “en-us;q=2.2250738585072012e-308”}

Just for an example try to run the following simple Java program which just tries to parse a Double value 2.2250738585072012e-308. As soon as you will run this program you will see that your JVM will Hang….and the CPU Utilization will be around 100%   😉

class HangJVM
  public static void main(String[] args)
      double d = Double.parseDouble("2.2250738585072012e-308");
      System.out.println("Value: " + d);

The JVMs which are affected are as following:
Java SE
JDK and JRE 6 Update 23 and earlier for Windows, Solaris, and Linux
JDK 5.0 Update 27 and earlier for Solaris 9
SDK 1.4.2_29 and earlier for Solaris 8

Java for Business
JDK and JRE 6 Update 23 and earlier for Windows, Solaris and Linux
JDK and JRE 5.0 Update 27 and earlier for Windows, Solaris and Linux
SDK and JRE 1.4.2_29 and earlier for Windows, Solaris and Linux

Save your JVM and your Application Server From Attack or Contact your Support 😉

Or Please get a Fix from Support  Which Updates the “rt.jar” of the JVM The Fix Details are available in the following Link  http://middlewaremagic.com/weblogic/?p=5393#comment-2821


Regarding the “Oracle Security Alert for CVE-2010-4476″You can get the Temp Security Patches related to this issue from the following link:http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

Jay SenSharma

Parts Of JVM And JVM Architecture Diagram?

Hi All,
Jay SenSharma

Jay SenSharma

JVM is the heart of any Java based Application Server. We face most of the issues deu to incorrect JVM tunning. It is very important to understand the Overall architecture of the JVM in order to trouble shoot different JVM tunning related issues.Here we are going to discuss the Architecture and the Major parts of a Java Process And the Java Heap Division.
The Following Diagram is just a basic overview of a Java Process in a 2 GB process Size Machine. Usually in 32 bit Windows Operating Systems the default process size will be 2 GB (In Unix based 64 bit operating Systems it can be 4GB or more). So i draw the following Diagram of Java Process to explain the Java Process partitions in a 2Gb process size machine.
Java Process Architecture Diagram

Java Process Architecture Diagram

In the above diagram we will find different partitions of a Java Process. Please compare the above diagram with below descriptions.
1). Just for Example we can see that Process Size is 2048 MB (2GB)
2). The Java Heap Size is 1024MB (means 1GB)   -Xmx1024m
3). Native Space = ( ProcessSize – MaxHeapSize – MaxPermSize) It means around 768 MB of Native Space.
4). MaxPermSpace is around -XX:MaxPermSize=256m
5). Young Generation Space is around    40% of Maximum Java Heap.

Could not reserve enough space for object heap

Many times while providing some value for the Max Heap or Max Perm we get the following kind of error:

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

In above case users should decrease JVM process size by decreasing the heap or permgen size or the Xss value. The cause of this error is insufficient memory.

The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems. As of Java SE 6, the Windows /3GB boot.ini feature is not supported.

Why to choose a 64-bit JVM?
A 64-bit capable J2SE is an implementation of the Java SDK (and the JRE along with it) that runs in the 64-bit environment of a 64-bit OS on a 64-bit processor.

The primary advantage of running Java in a 64-bit environment is the larger address space. This allows for a much larger Java heap size and an increased maximum number of Java Threads, which is needed for certain kinds of large or long-running applications. The primary complication in doing such a port is that the sizes of some native data types are changed. Not surprisingly the size of pointers is increased to 64 bits. On Solaris and most Unix platforms, the size of the C language long is also increased to 64 bits. Any native code in the 32-bit SDK implementation that relied on the old sizes of these data types is likely to require updating.

What Are these Different Parts?

Eden Space:

Eden Space is a Part of Java Heap where the JVM initially creates any objects, where most objects die and quickly are cleanedup by the minor Garbage Collectors (Note: Full Garbage Collection is different from Minor Garbage Collection). Usually any new objects created inside a Java Method go into Eden space and the objects space is reclaimed once the method execution completes. Where as the Instance Variables of a Class usually lives longer until the Object based on that class gets destroyed. When Eden fills up it causes a minor collection, in which some surviving objects are moved to an older generation.

Survivor Spaces:

Eden Sapce has two Survivor spaces. One survivor space is empty at any given time. These Survivor Spaces serves as the destination of the next copying collection of any living objects in eden and the other survivor space.
The parameter SurvivorRatio can be used to tune the size of the survivor spaces.
-XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6
If survivor spaces are too small copying collection overflows directly into the tenured generation.

Young Generation: (-XX:MaxNewSize)

Till JDK1.3 and 1.4 we used to set the Young Generation Size using -XX:MaxNewSize. But from JDK1.4 onwards we set the YoungGeneration size using (-Xmn) JVM option.
Young Generation size is controlled by NewRatio.  It means setting -XX:NewRatio=3 means that the ratio between the Old Generation and the Young Generation is  1:3
Similarly -XX:NewRatio=8 means that 8:1 ratio of tenured and young generation.
NewRatio: NewRatio is actually the ratio between the (YoungGenaration/Old Generations) has default values of 2 on Sparc , 12 on client Intel, and 8 everywhere else.
NOTE: After JDK 1.4 The Young Generation Size can be set using  (-Xmn) as well.

Virtual Space-1: (MaxNewSize – NewSize)

The First Virtual Space is actually shows the difference between the -XX:NewSize and -XX:MaxNewSize.  Or we can say that it is basically a difference between the Initial Young Size and the Maximum Young Size.

Java Heap Area: (-Xmx and -Xms)

Java Heap is a Memory area inside the Java Process which holds the java objects.  Java Heap is a combination of Young Generation Heap and Old Generation Heap. We can set the Initial Java Heap Size using -Xms JVM parameter similarly if we want to set the Maximum Heap Size then we can use -Xmx JVM parameter to define it.

-Xmx1024m —> Means Setting the Maximum limit of Heap as 1 GB
-Xms512m —> Means setting Java Heap Initial Size as 512m
NOTE-1): It is always recommended to set the Initial and the Maximum Heap size values as same for better performance.
NOTE-2): The Theoretical limitation of Maximum Heap size for a 32 bit JVM is upto 4GB. Because of the Memory Fragmentation, Kernel Space Addressing, Swap memory usages and the Virtual Machine Overheads are some factors JVM does not allow us to allocate whole 4GB memory for Heap in a 32 bit JVM. So usually on 32-bit Windows Operating Systems the Maximum can be from 1.4 GB to 1.6 GB.
If we want a Larger memory allocation according to our application requirement then we must choose the 64-bit operating systems with 64 bit JVM. 64-bit JVM provides us a larger address space. So we can have much larger Java Heap  with  the increased number of Threads allocation area. Based on the Nature of your Operating system in a 64 bit JVM you can even set the Maximum Heap size upto 32GB.
Example:        -Xms32g -Xmx32g -Xmn4g

Virtual Space-2: (MaxHeapSize – InitialHeapSize)

The Second Virtual Space is actually the Difference between the Maximum Heap size (-Xmx)and the Initial Heap Size(-Xms). This is called as virtual space because initially the JVM will allocate the Initial Heap Size and then according to the requirement the Heap size can grow till the MaxHeapSize.

PermGen Space: (-XX:MaxPermSize)

PermGen is a non-heap memory area where the Class Loading happens and the JVM allocates spaces for classes, class meta data,  java methods and the reference Objects here. The PermGen is independent from the Heap Area. It can be resized according to the requirement using -XX:MaxPermSize and -XX:PermSize  JVM Options. The Garbage collection happens in this area of JVM Memory as well. The Garbage collection in this area is called as “Class GC”. We can disable the Class Garbage Collection using the JVM Option -noclassgc. if  “-noclassgc” Java Option is added while starting the Server. In that case the Classes instances which are not required will not be Garbage collected.

Native Area:

Native Memory is an area which is usually used by the JVM for it’s internal operations and to execute the JNI codes. The JVM Uses Native Memory for Code Optimization and for loading the classes and libraries along with the intermediate code generation.
The Size of the Native Memory depends on the Architecture of the Operating System and the amount of memory which is already commited to the Java Heap. Native memory is an Process Area where the JNI codes gets loaded or JVM Libraries gets loaded or the native Performance packs and the Proxy Modules gets loaded.
There is no JVM Option available to size the Native Area. but we can calculate it approximately using the following formula:
NativeMemory = (ProcessSize – MaxHeapSize – MaxPermSize)
Jay SenSharma

Using Jps.exe to distinguish WLS ProcessIDs


Jay SenSharma

Jay SenSharma

Many times as a Weblogic Admin We find difficulty to identify the Process Id of our WebLogic Server …using (ps   -ef   |   grep   java) command Or the Step described in the Step2). of the following Link:  weblogic-heap-dump-genration-using-jmap/ …When There are more than one WebLogic Servers are running on the same Physical Box. So in this case we can use the “jps.exe” utility to easily get the process ID of each WebLogic Server.This utility can be seen inside ANY “<JAVA_HOME>binjps.exe”.

NOTE: jps.exe utility is available from JDK1.5 Onwards By Default.

Step1). Run Two or More than 2 WebLogic Server Instances in the same Physical Box.

Step2). Now open a command prompt and move inside the “<JAVA_HOME>bin” directory …And then run the command:

jps.exe     -v

Uniquely Finding Different WLS instances Process ID

Uniquely Finding Different WLS instances Process ID

In the above outout u can see that  when we run the “jps.exe    -v”  then it shows all the JAVA_OPTIONS of the Server including the WebLogic Property…  -Dweblogic.Name which represents the configured name of the Running WebLogic  Server.  This helps us to easily distinguish the correct process ID for our running Servers.

Not only the Process ID, Rather using the above tool we can see all the System property which has been taken by the WLS server as well as the Heap Settings…etc

Some other Options which can be used with jps.exe utility:

Output the arguments passed to the main method. The output may be null for embedded JVMs.
Output the full package name for the application’s main class or the full path name to the application’s JAR file.
Output the arguments passed to the JVM.
Output the arguments passed to the JVM through the flags file

Jay SenSharma

Copyright © 2010-2012 Middleware Magic. All rights reserved. |