Tuesday, March 13, 2012

XML and XSLT

XML stands for eXtensible Markup Language.

XML is designed to transport and store data.

Simple xml document





XSL stands for EXtensible Stylesheet Language, and is a style sheet language for XML documents.

XSLT stands for XSL Transformations. In this tutorial you will learn how to use XSLT to transform XML documents into other formats, like XHTML.

Steps to use XSLT to transform XML documents into other formats ,like XHTML .

Step1 : Create a simple xml document ,like the one given below called ash.xml

























Step2 : Create an xsl file ,like the one given below ,save it as ash.xsl
































Step 3 :
Modify the first xml document ,that is ash.xml and add the line



under


Here we are including the xsl which we created in step2,so that the xml file will be dispalyed in the form of table ....and we are using
and
respectively .


So you ash.xml will be like below































step 4:

Access the xml document ash.xml from a browser .

C:\Documents and Settings\ashraf\Desktop\oracle\Oracle Materials\XML\ash.xml

Wednesday, March 7, 2012

Reading Threaddump

1. Introduction
In my opinion, one of the greatest things about Java is the ability to get meaningful thread dumps on a running production environment without having to enable DEBUG mode. The thread dump is a snapshot of exactly what's executing at a moment in time. While the thread dump format and content may vary between the different Java vendors, at the bare minimum it provides you a list of the stack traces for all Java threads in the Java Virtual Machine. Using this information, you can either analyze the problem yourself, or work with those who wrote the running code to analyze the problem.

2. What is a stack trace?
I mentioned earlier that the thread dump is just a list of all threads and the full stack trace of code running on each thread. If you are a J2EE Application Server administrator and you've never done development before, the concept of a stack trace may be foreign to you. A stack trace is a dump of the current execution stack that shows the method calls running on that thread from the bottom up. If you're unfamiliar with what a method is, please see: http://en.wikipedia.org/wiki/Subroutine.

Here is an example stack trace for a thread running in WebLogic:

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=1 tid=0x0938ac90 nid=0x2f53 waiting for monitor entry [0x80c77000..0x80c78040]
at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:95)
- waiting to lock <0x8d3f6df0> (a weblogic.socket.PosixSocketMuxer$1)
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
You don't need to understand what it's doing at the moment, but the key point to remember is that it is bottom up. This means that it started with weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117), that method called the "execute" method above it which called the one above it and so on.

The key here is knowing that what is currently running (or waiting) is always the top method. This will give you insight as to what the threads are stuck on. I usually glance through the whole stack trace because developers usually provide clues in method names as to what is actually going on. In the above thread, you'll notice that the method currently running (or in this case, waiting on a java lock) is weblogic.socket.PosixSocketMuxer.processSockets(). Socket Muxer is a term used by BEA and others to refer to managing data on network sockets (data sent across the network interface)

3. Thread pools
Most application servers use thread pools to manage execution tasks of a certain type. A thread pool is merely a collection of threads set aside for a specific task. In the example thread above, I've shown you a thread from the WebLogic thread pool (or queue) named "weblogic.socket.Muxer". A pool of these "Muxer threads" is set aside by WebLogic to manage reading and writing data for network connections coming into WebLogic.

In most cases, you won't be looking at the Muxer threads. When someone reports that the application server isn't responding, it usually means that the application code deployed to the application server isn't working right - and you'll need to figure out why. So you'll need to identify the thread pool that your application code runs on and find those threads in the Java thread dump to see what's going on.

Unless you've customized the execute queue/thread pool that your application gets deployed too, you'll want to look for the given application servers "Default" execute queue. In WebLogic, you'll look for the threads marked as 'weblogic.kernel.Default' to see whats running.

For WebLogic 10, here is an example of just such a thread:

"[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=1 tid=0x091962f8 nid=0x2f95 in Object.wait() [0x7cd75000..0x7cd75ec0]
at java.lang.Object.wait(Native Method)
- waiting on <0x8ed19d28> (a weblogic.work.ExecuteThread)
at java.lang.Object.wait(Object.java:474)
at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:156)
- locked <0x8ed19d28> (a weblogic.work.ExecuteThread)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:177)
In WebLogic, when you see the keyword "waitForRequest" in a particular thread's stack trace, it means that the thread is idle and could potentially do work if a new request came in. Having idle threads is usually a good thing, but it doesn't always guarantee that your application is healthy or responsive. It just means that you have the potential for more throughput.

Once you know which execute queue is used for the unresponsive application code, you know exactly where to look to figure out what's going on.

4. Getting a thread dump
There are quite a few ways to obtain a thread dump from a running virtual machine. I've found that the easiest way to get a thread dump is to send the HUP or BREAK signal to the java process. In Unix, this is done by figuring out the PID (process ID) of the Java virtual machine and doing a "kill -3 ".

In Windows, you can use the SendSignal.exe program to send a "break" signal to the process and obtain a thread dump.

Where you go to find the thread dump usually depends on Java implementation. For most vendors, you'll go to the "standard out" log file. In WebLogic, it's often referred to as "weblogic.out", "nohup.out" or something you've created yourself by redirecting standard output to a file. This is why it's critical to redirect standard output & standard error to a log file so it is captured when you need a thread dump. See http://www.javasanity.org/basicsetup for information on how to do this.

For the IBM Java, the thread dump gets printed to a file with a prefix of "javacore" in it's name. The file gets written to the Java process "working directory". You may have to do some digging to find it.

5. Full Thread dump
Take a look at this example thread dump taken from WebLogic 10 while running some sample requests. You can look at this to get familiar with the format of a WebLogic thread dump running in the Sun JVM. Take a moment to search for the default execute queue and figure out what the code was doing when this thread dump was taken Don't read the next section until you're sure you want the answer.

6. Summary
Being able to obtain and analyze Java thread dumps is critical for understanding what's really going in inside your J2EE application server. Without thread dumps, you're blind when it comes to trying to get to root cause for an application server "hang" condition. I'd suggest always getting a thread dump before restarting a hung or misbehaving application server. It might not always be useful, but it doesn't hurt to get one in case it's needed later.

If you took the time to analyze the full thread dump in section 5, I hope you took the time to find the threads marked "weblogic.kernel.Default" to see what's going on. In this thread dump, there are only two types of requests running on the Default queue. There are idle threads (which are not the issue) and there are threads running my "insert_test.jsp" java server page.

If you found that they all were doing something within "Oracle" routines, kudos to you. If you understand network programming, you might even have realized that when the top function is doing a "socketRead", it's waiting on data to come across the network. Seeing most of your executing threads waiting on data from the network is usually a pointer to the next place you need to look to identify the cause of your problem.

What I provided here was a simulation of database issue. In this case, all running "Default" threads were waiting on a response from the database. This response was never going to come, because I locked the table in exclusive mode and the jsp was trying to do an insert. I solved this by killing the lock - this allowed the threads to complete. A poorly tuned database (missing or corrupt indexes, SGA, disk I/O, high CPU on the DB, etc) can cause a similar "socketRead" bottleneck within the jdbc drivers for your application. I've also found that poorly designed SQL code or tables that were too large and never purged can cause this as well.



Creating Thread Dumps
To create a thread dump from a process, do either of the following:

■Press Ctrl-Break while the process is running (or by sending SIGQUIT to the process on Linux).
■Enter the following at the command line at startup:
bin\jrcmd.exe print_threads
The thread dump appears at the command line.

Note: For more information about jrcmd and Ctrl-Break handlers, see Running Diagnostic Commands.




--------------------------------------------------------------------------------

Reading Thread Dumps
This section describes the typical contents of a thread dump by going through an example thread dump from the beginning to end. First, an example thread dump, broken up into its components is presented (see Listing 20-1, Listing 20-2, Listing 20-3, Listing 20-4 and Listing 20-5). First, information about the main thread is printed, then all the JVM internal threads, followed by all other Java application threads (if there are any). Finally, information about lock chains are printed.

The example thread dump is taken from a program that creates three threads that are quickly forced into a deadlock. The application threads Thread-0, Thread-1, and Thread-2 correspond to three different classes in the Java code.

The Beginning of The Thread Dump
The thread dump starts with the date and time of the dump, and the version number of the JRockit JVM used (see Listing 20-1).

Listing 20-1 The initial information of a thread dump
===== FULL THREAD DUMP ===============Wed Feb 21 13:46:45 2007BEA JRockit(R) R27.1.0-109-73164-1.5.0_08-20061129-1428-windows-ia32Stack Trace for Main Application Thread
Listing 20-2 shows the stack trace of the main application thread. There is a thread information line, followed by information about locks and a trace of the thread’s stack at the moment of the thread dump.

Listing 20-2 The main thread in the thread dump
"Main Thread" id=1 idx=0x2 tid=48652 prio=5 alive, in native, waiting-- Waiting for notification on: util/repro/Thread1@0x01226528[fat lock]at jrockit/vm/Threads.waitForSignal(J)Z(Native Method)at java/lang/Object.wait(J)V(Native Method)at java/lang/Thread.join(Thread.java:1095)^-- Lock released while waiting: util/repro/Thread1@0x01226528[fat lock]at java/lang/Thread.join(Thread.java:1148)at util/repro/DeadLockExample.main(DeadLockExample.java:23)at jrockit/vm/RNI.c2java(IIII)V(Native Method)-- end of traceAfter the name and other identification information, the different status messages of the main thread are printed. The main thread in Listing 20-2 is a running thread (alive), it is either executing JVM internal code or user-defined JNI code (in native), and it is currently waiting for an object to be released (waiting). If a thread is waiting on a notification on a lock (by calling Object.wait()), this is indicated at the top of the stack trace as Waiting for notification on.

Locks and Lock Chains
For each thread, the JRockit JVM prints the following information:

■If the thread is trying to take a lock (to enter a synchronized block), but the lock is already held by another thread, this is indicated at the top of the stack trace, as “Blocked trying to get lock”.
■If the thread is waiting on a notification on a lock (by calling Object.wait()), this is indicated at the top of the stack trace as “Waiting for notification”.
■If the thread has taken any locks, this is shown in the stack trace. After a line in the stack trace describing a function call is a list of the locks taken by the thread in that function. This is described as ^-- Holding lock (where the ^-- serves as a reminder that the lock is taken in the function written above the line with the lock).
The semantics for waiting (for notification) on an object in Java is somewhat complex. First, to enter a synchronized block, you must take the lock for the object, and then you call wait() on that object. In the wait method, the lock is released before the thread actually goes to sleep waiting for a notification. When it receives a notification, wait re-takes the lock before returning. So, if a thread has taken a lock, and is waiting (for notification) on that lock, the line in the stack trace that describes when the lock was taken is not shown as “Holding lock,” but as “Lock released while waiting.”

All locks are described as Classname@0xLockID[LockType]; for example:

java/lang/Object@0x105BDCC0[thin lock]Classname@0xLockID describe the object to which the lock belongs. The classname is an exact description, the fully qualified classname of the object. LockID, on the other hand, is a temporary ID which is only valid for a single thread dump. That is, you can trust that if a thread A holds a lock java/lang/Object@0x105BDCC0, and a thread B is waiting for a lock java/lang/Object@0x105BDCC0, in a single thread dump, then it is the same lock. If you do any subsequent thread dumps however, LockID is not comparable and, even if a thread holds the same lock, it might have a different LockID and, conversely, the same LockID does not guarantee that it holds the same lock. LockType describes the JVM internal type of the lock (fat, thin, recursive, or lazy). The status of active locks (monitors) is also shown in stack traces.

Presentation of Locks Out of Order
The lines with the lock information might not always be correct, due to compiler optimizations. This means two things:

■If a thread, in the same function, takes lock A first and then lock B, the order in which they are printed is unspecified.
■If a thread, in method foo() calls method bar(), and takes a lock A in bar(), the lock might be printed as being taken in foo().
Normally, this should not be a problem. The order of the lock lines should never move much from their correct position. Also, lock lines will never be missing—you can be assured that all locks taken by a thread are shown in the thread dump.

JVM Internal Threads
Listing 20-3 shows the traces of JVM internal threads. The threads have been marked as daemon threads, as can be seen by their daemon state indicators. Daemon threads are either JVM internal threads (as in this case) or threads marked as daemon threads by java.lang.Thread.setDaemon().

Listing 20-3 The first and last thread in a list of JVM internal Threads
"(Signal Handler)" id=2 idx=0x4 tid=48668 prio=5 alive, in native, daemon[...]"(Sensor Event Thread)" id=10 idx=0x1c tid=48404 prio=5 alive, in native, daemonAs you can see, lock information and stack traces are not printed for the JVM internal threads in Listing 20-3. This is the default setting.

If you want to see stack traces for the JVM internal threads, then use the parameter nativestack=true when you send the print_threads handler. At the command line, write the following:

bin\jrcmd.exe print_threads nativestack=true

Other Java Application Threads
Normally, you will primarily be interested in the threads of the Java application you are running (including the main thread). All Java application threads except the main thread are presented near the end of the thread dump. Listing 20-4 shows the stack traces of three different application threads.

Listing 20-4 Additional application threads
"Thread-0" id=11 idx=0x1e tid=48408 prio=5 alive, in native, blocked-- Blocked trying to get lock: java/lang/Object@0x01226300[fat lock]at jrockit/vm/Threads.waitForSignal(J)Z(Native Method)at jrockit/vm/Locks.fatLockBlockOrSpin(ILjrockit/vm/ObjectMonitor;II)V(Unknown Source)at jrockit/vm/Locks.lockFat(Ljava/lang/Object;ILjrockit/vm/ObjectMonitor;Z)Ljava/lang/Object;(Unknown Source)atjrockit/vm/Locks.monitorEnterSecondStage(Ljava/lang/Object;I)Ljava/lang/Object;(Unknown Source)at jrockit/vm/Locks.monitorEnter(Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)at util/repro/Thread1.run(DeadLockExample.java:34)^-- Holding lock: java/lang/Object@0x012262F0[thin lock]^-- Holding lock: java/lang/Object@0x012262F8[thin lock]at jrockit/vm/RNI.c2java(IIII)V(Native Method)-- end of trace"Thread-1" id=12 idx=0x20 tid=48412 prio=5 alive, in native, blocked-- Blocked trying to get lock: java/lang/Object@0x012262F8[thin lock]at jrockit/vm/Threads.sleep(I)V(Native Method)at jrockit/vm/Locks.waitForThinRelease(Ljava/lang/Object;I)I(Unknown Source)at jrockit/vm/Locks.monitorEnterSecondStage(Ljava/lang/Object;I)Ljava/lang/Object;(Unknown Source)at jrockit/vm/Locks.monitorEnter(Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)at util/repro/Thread2.run(DeadLockExample.java:48)at jrockit/vm/RNI.c2java(IIII)V(Native Method)-- end of trace"Thread-2" id=13 idx=0x22 tid=48416 prio=5 alive, in native, blocked
-- Blocked trying to get lock: java/lang/Object@0x012262F8[thin lock]
at jrockit/vm/Threads.sleep(I)V(Native Method)
at jrockit/vm/Locks.waitForThinRelease(Ljava/lang/Object;I)I(Unknown Source)
at jrockit/vm/Locks.monitorEnterSecondStage(Ljava/lang/Object;I)Ljava/lang/Object;(Unknown Source)
at jrockit/vm/Locks.monitorEnter(Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)
at util/repro/Thread3.run(DeadLockExample.java:65)
^-- Holding lock: java/lang/Object@0x01226300[fat lock]
at jrockit/vm/RNI.c2java(IIII)V(Native Method)
-- end of trace

All three threads are in a blocked state (indicated by blocked), which means that they are all trying to enter synchronized blocks. Thread-0 is trying to take Object@0x01226300[fat lock] but this is held by Thread-2. Both Thread-2 and Thread-1 are trying to take Object@0x012262F8[thin lock] but this lock is held by Thread-0. This means that Thread-0 and Thread-2 form a deadlock, while Thread-1 is blocked.

Lock Chains
One prominent feature of the JRockit JVM is that it automatically detects deadlocked, blocked and open lock chains among the running threads. The analysis in Listing 20-5 presents the all the lock chains created by the threads T1, T2, T3, T4 and T5. This information can be used to tune and troubleshoot your Java code.

Listing 20-5 Deadlocked and blocked lock chains
Circular (deadlocked) lock chains=================================Chain 6:"Dead T1" id=16 idx=0x48 tid=3648 waiting for java/lang/Object@0x01225018 held by:"Dead T3" id=18 idx=0x50 tid=900 waiting for java/lang/Object@0x01225010 held by:"Dead T2" id=17 idx=0x4c tid=3272 waiting for java/lang/Object@0x01225008 held by:"Dead T1" id=16 idx=0x48 tid=3648Blocked lock chains===================Chain 7:"Blocked T2" id=20 idx=0x58 tid=3612 waiting for java/lang/Object@0x01225310 held by:"Blocked T1" id=19 idx=0x54 tid=2500 waiting for java/lang/Object@0x01224B60 held by: "Open T3" id=13 idx=0x3c tid=1124 in chain 1Open lock chains================Chain 1:"Open T5" id=15 idx=0x44 tid=4048 waiting for java/lang/Object@0x01224B68 held by:"Open T4" id=14 idx=0x40 tid=3380 waiting for java/lang/Object@0x01224B60 held by:"Open T3" id=13 idx=0x3c tid=1124 waiting for java/lang/Object@0x01224B58 held by:"Open T2" id=12 idx=0x38 tid=3564 waiting for java/lang/Object@0x01224B50 held by:"Open T1" id=11 idx=0x34 tid=2876 (active)


--------------------------------------------------------------------------------

Thread Status in Thread Dumps
This section describes the different statuses or states a thread can show in a thread dump. There are three types of states:

■Life States
■Run States
■Special States
Life States
Table 20-1 describes the life states a thread can show in a thread dump.


Table 20-1 Thread Life States State Description
alive This is a normal, running thread. Virtually all threads in the thread dump will be alive.
not started The thread has been requested to start running by java.lang.Thread.start(), but the actual OS process has not yet started, or executed far enough to pass control to the JRockit JVM. It is extremely unlikely to see this value. A java.lang.Thread object that is created, but not has had start() executed, will not show up in the thread dump.
terminated This thread has finished its run() method and has also notified any threads joining on it, but it is still kept in the JVM internal thread structure for running threads. It is extremely unlikely to see this value. A thread that has been terminated for a time longer than a few milliseconds will not show up in the thread dump.


Run States
Table 20-2 describes the run states a thread can show in a thread dump.


Table 20-2 Thread Run States State Description
blocked This thread has tried to enter a synchronized block, but the lock was taken by another thread. This thread is blocked until the lock gets released.
blocked (on thin lock) This is the same state as blocked, but with the additional information that the lock in question is a thin lock.
waiting This thread has called Object.wait() on an object. The thread will remain there until some other thread sends a notification on that object.
sleeping This thread has called java.lang.Thread.sleep().
parked This thread has called java.util.concurrent.locks.LockSupport.park().
suspended The thread’s execution has been suspended by java.lang.Thread.suspend() or a JVMTI/JVMPI agent call


Special States
Table 20-3 describes the special states a thread can show in a thread dump. Note that all these states are not mutually exclusive.




--------------------------------------------------------------------------------

Troubleshooting with Thread Dumps
This section contains information on about how to use thread dumps for troubleshooting and diagnostics.

To use thread dumps for troubleshooting, beyond detecting deadlocks, you need to take several thread dumps from the same process. However, if you want to do long time analysis of behavior you will likely be more helped by combining occasional thread dumps with other diagnostics tools, such as the JRockit Runtime Analyzer, which is part of Oracle JRockit Mission Control (see Using Oracle JRockit Mission Control Tools for more information).

Detecting Deadlocks
The Oracle JRockit JVM automatically analyzes the thread dump information and detects whether there exists any circular (deadlocked) or blocked lock chains in it.

Detecting Processing Bottlenecks
For detecting more than deadlocks in your threads, you have to make several consecutive thread dumps. This lets you detect the occurrence of contention, where multiple threads are trying to get the same lock. Contention might create long open lock chains that, while not deadlocked, will degrade performance.

If you discover (in a set of consecutive thread dumps) that one or more threads in your application is temporarily stuck waiting for a lock to be released, then you might have reason to look over the code of your Java application to see if the synchronization (serialization) is necessary or if the threads can be organized differently.

Viewing The Runtime Profile of an Application
By making several consecutive thread dumps, you might quickly get an overview of which parts of your Java application that are most heavily used. However, you should consult the Threads tab in JRockit Management Console for more detailed information about the workload on the different parts of your application.

JVM Architecture

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.
Example:
-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)

Permanent Generation in Java

Permanent Generation is a Non-Heap Memory Area inside the JVM Space. Manytimes we see OutOfMemory in this Area. PermGen Area is NOT present in JRockit JVMs. For more details on this area please refer to: http://middlewaremagic.com/weblogic/?p=4456.
.
The PermGen Area is measured independently from the other generations because this is the place where the JVM allocates Classes, Class Structures, Methods and Reflection Objects. PermGen is a Non-Heap Area.It means we DO NOT count the PermGen Area as part of Java Heap.
The OutOfMemory in PermGen Area can be seen because of the following main reasons:
Point-1). Deploying and Redeploying a very Large Application which has many Classes inside it.
.
Point-2). If an Application is getting deployed/Updated/redeployed repeatedly using the Auto Deployment feature of the Containers. In that case the Classes belonging to the application stays un cleaned and remains in the PermGen Area without Class Garbage Collection.
.
Point-3). 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.
.
Point-4). Very Less Space for allocated the “=XX:MaxPermGen”
Example: you can see following kind of Trace in the Server/Stdout Logs:



02 Exception in thread "[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" java.lang.OutOfMemoryError: PermGen space

03 at java.lang.ClassLoader.defineClass1(Native Method)

04 at java.lang.ClassLoader.defineClass(ClassLoader.java:621)

05 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

06 at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)

07 at java.net.URLClassLoader.access$000(URLClassLoader.java:56)

08 at java.net.URLClassLoader$1.run(URLClassLoader.java:195)

09 at java.security.AccessController.doPrivileged(Native Method)

Tuesday, March 6, 2012

Managed server not starting

Issue :Authentication for user weblogic denied

#### <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1331026721734>
#### <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1331026721750>
####
<> <> <> <1331026721750> weblogic.security.SecurityInitializationException: Authentication for user weblogic denied

Solution :

Root cause #1

The Weblogic boot.properties file is corrupted or contains invalid principal and credentials


Solution >> boot.properties reset

· Backup and clear the cache and data directories under /servers/
· Recreate boot.properties (put back your plain text username and password) under /servers//security directory and restart the affected server(s)


Root cause #2

The Weblogic boot.properties file is valid but the security realm is corrupted or in an invalid state


Solution >> Weblogic Admin username and password reset

· Backup your Weblogic server domain
· Rename or delete /security/DefaultAuthenticatorInit.ldift
· Run the following Java command:
java weblogic.security.utils.AdminAccount </security >
· Delete the contents inside the file boot.properties under /servers/< AdminServer>/security
· Add the following contents inside the boot.properties
username=
password=
· Backup and delete the folder: /servers//data/ldap
· Restart your Weblogic server

Node Manager Not Reachable in windows/linux

http://onlineappsdba.com/index.php/2011/02/14/webloigic-node-manager-associated-with-this-machine-is-not-reachable-access-to-domain-base_domain-for-user-xxxxx-denied/


This post covers “Node Manager not reachable/inactive ” from admin console , a very common issue that we face , especially in a Clustered Setup or starting Managed Servers on remote machine.

For basics about Node Manager refer this Link.

In our case, we had the Admin Server& Webcenter Spaces Managed Server1 on one Machine1 & Webcenter Spaces Managed Server 2 on Machine2. More on WebCenter deployment in High Availability here

After pack & unpack the domain jar file (for more on pack & unpack scripts please check this link) on Machine2, We started the nodemanager.

It started successfully without any errors but when we checked the status of nodemanger in console under Environment–>Machines–>[Machine2] –>Monitoring–>Node Manager , it showed node manager not reachable.

Verified

• Node Manager for Machine2 was configured correctly
• Host Name verification was disabled, checked that listener is running on 5556
still Node Manager on Machine2 was not reachable from Admin Console, hence time to check Admin Server log file ($DOMAIN_HOME/servers/AdminServer/logs) :

Could not execute command “getVersion” on the node manager. Reason: “Access to domain ‘base_domain’ for user ‘vfPYmgWF1Y’ denied”.

The issue was that Node Manager on Machine2 was not enrolled with Admin Server on Machine1.

As per the doc here , we must run
nmEnroll()
on all remote machines that are running a Managed Server. Additionally, you should run
nmEnroll()
for each domain directory on each machine (If you have different domain directory for Admin Server and Managed server on same machine as mentioned here).

Follow below steps to enroll the Node Manager using WLST command:-

1) Set environment by running setWLSEnv.sh (linux)/setWLSEnv.cmd (windows) under $WEBLOGIC_HOME/server/bin

2) java weblogic.WLST

wls:/offline> connect(’[weblogic_user]’,'[user_password]’,'t3://[hostname]:[admin port]’)

wls:/base_domain/serverConfig> nmEnroll(’[MW_HOME]/user_projects/domains/base_domain’,'[WL_HOME]/common’)

You should get output like “Successfully enrolled this machine with the domain directory at $Middleware_Home/user_projects/domains/base_domain”

After this restart the nodemanager & it will now be accessible from admin

Node Manger not reachable

1. start the AdminServer using startScript “startWebLogic.sh/cmd”
Step2) Start the NodeManager.
Step3) Login to admin-console and then see if the NodeManager is Reachable or not at the below console path
Console Path:
Machines -> -> Monitoring (tab) -> Node Manager Status (sub-tab) -> Status: Reachable
If its NOT REACHABLE then please do the following from the Admin Server Box to Enroll the NodeManager
view source

print?
1 a) Open a command prompt and run "setWLSEnv.sh/cmd" in it then run the following commands
2
3 java weblogic.WLST
4 connect('weblogic','weblogic','t3://localhost:7001')

5 nmEnroll('C:/bea103/user_projects/domains/7001_Domain','C:/bea103/wlserver_10.3/common/nodemanager')
6

7 b)Then again check in the console path if NodeManager is Reachable.
Step4). Once NodeManager is Enrlolled and Reachable in the admin console then continue the following steps.
Step5). Kill the AdminServer because now we need to start it using WLST command nmStart() and NOT using the start scripts.
Step6). Open a command prompt run “setWLSEnv.sh/cmd” and then run the following command
view source

print?
1 java weblogic.WLST
Step7). Now connect to the NodeManager using the following command (7001_Domain is the Domain Name for example.)
view source

print?
1 nmConnect('weblogic','weblogic','localhost','5556','7001_Domain')
Step8). Once you are successfully connected to the Nodemanager please start the AdminServer using the following command
view source

print?
1 nmStart('AdminServer')
Step9). Once the Server is started run the following command to get the AdminServer Status
view source

print?
1 nmServerStatus('AdminServer')
Now if you can see the Admin Server status that means now your AdminServer is now reachable. Hope these steps solves your NodeManager is not reachable

Node Manger not reachable

1. start the AdminServer using startScript “startWebLogic.sh/cmd”
Step2) Start the NodeManager.
Step3) Login to admin-console and then see if the NodeManager is Reachable or not at the below console path
Console Path:
Machines -> -> Monitoring (tab) -> Node Manager Status (sub-tab) -> Status: Reachable
If its NOT REACHABLE then please do the following from the Admin Server Box to Enroll the NodeManager
view source

print?
1 a) Open a command prompt and run "setWLSEnv.sh/cmd" in it then run the following commands
2
3 java weblogic.WLST
4 connect('weblogic','weblogic','t3://localhost:7001')

5 nmEnroll('C:/bea103/user_projects/domains/7001_Domain','C:/bea103/wlserver_10.3/common/nodemanager')
6

7 b)Then again check in the console path if NodeManager is Reachable.
Step4). Once NodeManager is Enrlolled and Reachable in the admin console then continue the following steps.
Step5). Kill the AdminServer because now we need to start it using WLST command nmStart() and NOT using the start scripts.
Step6). Open a command prompt run “setWLSEnv.sh/cmd” and then run the following command
view source

print?
1 java weblogic.WLST
Step7). Now connect to the NodeManager using the following command (7001_Domain is the Domain Name for example.)
view source

print?
1 nmConnect('weblogic','weblogic','localhost','5556','7001_Domain')
Step8). Once you are successfully connected to the Nodemanager please start the AdminServer using the following command
view source

print?
1 nmStart('AdminServer')
Step9). Once the Server is started run the following command to get the AdminServer Status
view source

print?
1 nmServerStatus('AdminServer')
Now if you can see the Admin Server status that means now your AdminServer is now reachable. Hope these steps solves your NodeManager is not reachable

OBIEE 11g weblogic admin password Reset

Oracle BI Enterprise Edition OBIEE 11g has been integrated into the Fusion Middleware and now runs on Weblogic server. Therefore it also requires an administrator password to manage Weblogic server. By default, the administrator account is called 'weblogic'. the procedure to manage the weblogic administrator account password is similar to any other platform running on Weblogic server.

If for security reasons you ever want to change the administrator password at specific time intervals or you have to work on a platform you do not usually manage and the weblogic adminserver password is unknown (step 1 below would not apply) or any other weblogic server (for instance your forms and reports server 11g enterprise manager password), you can proceed with following steps to reset this password on Weblogic Server 10.3 (WLS 11g):

1. Shutdown WebLogic server from a command line session:

export MWHOME=[MiddlewareHome]
export DOMAIN_HOME=[BI_DomainHome]
export CLASSPATH=$CLASSPATH:$MWHOME/wlserver_10.3/server/lib/weblogic.jar
cd $DOMAIN_HOME/bin
./stopWebLogic.sh

(enter existing username [weblogic] and old password when prompted)

Example values for these environment variables:

export MWHOME=/u01/app/oracle/Middleware
export DOMAIN_HOME=/u01/app/oracle/Middleware/user_projects/domains/bifoundation_domain
2. Still in the same command line session, populate the correct values of the environment variables for your (OBI) Domain:

cd $DOMAIN_HOME/bin
./setDomainEnv.sh
3. To disable the default authenticator initialisation file and still retain a backup copy, rename it:

cd $DOMAIN_HOME/security
mv DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift.bak
4. Generate an administrator password for a new temporary (or permanent) administration account, e.g. called wlsadmin, into a new DefaultAuthenticatorInit.ldift file using the syntax below. Please do not leave the security directory and mind the trailing dot:

java weblogic.security.utils.AdminAccount [adminUserName] [adminPassword] .
5. Backup and disable the boot properties file, if exists, as well as the 'DefaultAuthenticatormyrealmInit.initialized' file in the ldap directory of the domain:

cd $DOMAIN_HOME/servers/AdminServer/data/ldap
mv DefaultAuthenticatormyrealmInit.initialized DefaultAuthenticatormyrealmInit.initialized.bak
cd ../../security
mv boot.properties boot.properties.bak

Please never rename the directory 'ldap' where the 'DefaultAuthenticatormyrealmInit.initialized' file was disabled abovem nor its entire parent directory 'data'. Doing this would cause the loss of all existing users and may even remove default OBI users and groups. A safety copy of the directory 'data' is recommended:

cd $DOMAIN_HOME/servers/AdminServer
cp -R data data.bak
6. Restart the Admin Server using the new administrator account. If it is possible to start in the foreground, proceed as follows:

cd $DOMAIN_HOME
./startWebLogic.sh

If you operate the Weblogic server from a remote terminal session and want to run the server in the background, one can proceed like this (assuming boot.properties has not been configured previously):

cd $DOMAIN_HOME/servers/AdminServer/security
echo username=wlsadmin > boot.properties (1)
echo password=******>>boot.properties (2)
cd $DOMAIN_HOME
nohup ./startWebLogic.sh >> Adminserver.log 2>&1 & (3)
tail -f Adminserver.log (4)


Please avoid blank lines in boot.properties file. The clear text username and password will be encrypted the first time Weblogic server has been started.

In WebLogic Server 11g Administration Console, logon using the new administration account, e.g. 'wlsadmin'. Do not use the old account 'weblogic'. By default, you can reach this console using your web browser at URL:

servername:7001/console

Navigate through the domain structure to:
bifoundation_domain/Security Realms
select 'myrealm', press the command button 'Lock & Edit' and enable the tabs

Users and Groups / weblogic

to change the password of this old administration account.

From now on, the Enterprise Manager Fusion Middleware Control 11g and the WebLogic Server 11g Administration Console can be accessed with the new administration account as well as using the new password for account 'weblogic'.

Optionally, also grant the new 'wlsadmin' account OBI administration privileges by assigning the group 'BIAdministrators ' to it, save and press 'Release Configuration'.
_____________________
(1) Please use the WLS admin account "adminUserName" created above in step 4, this should not be "weblogic" when following this publication.
(2) Better add this password through a text editor as it may end up in history.
(3) To start WLS in the background and have it running when disconnecting your terminal session.
(4) To monitor the startup process. You can send the Break signal with CTRL+C when reading the expected log entry:
" "


These steps have been tested on both Oracle Fusion Middleware 11g Release 1 Business Intelligence Foundation OBIEE releases 11.1.1.3.0 and 11.1.1.5.0 deployed on x86-64 bit


Reference : http://linora64.blogspot.com/2011/07/reset-obiee-11g-weblogic-admin-password.html

Monday, March 5, 2012

demo hrapp application

oc4j hrapp

http://download.oracle.com/otndocs/tech/ias/portal/files/RG/OBE/deployToAppServer/lesson_Deployment.htm


web logic hrapp
http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/10g/r3/appdeploy/deploy/deploy_plan/deploy_plan.htm
http://download.oracle.com/otndocs/tech/ias/portal/files/RG/OBE/deployj2ee/deployj2ee.htm

Sunday, March 4, 2012

Java Program to Connect to Oracle DB

1. Include the library Ojdbc6.jar ..
2. Write the Java Code
3. Execute the Code


1. Include the library Ojdbc6.jar
Write click on Application ,Properties, ,Libraries and Class Path -> Add JAR/Directory .click Add ...

2. Write the Java code below .

package project1;

import java.sql.*;

class class1 {
public static void main(String args[]) throws SQLException {
DriverManager.registerDriver(
new oracle.jdbc.driver.OracleDriver()
);
String serverName = "mohammed-pc.in.oracle.com";
int port = 1521;
String user = "ashraf";
String password = "ashraf";
String SID = "orcl";
String URL = "jdbc:oracle:thin:@" + serverName + ":" + port + ":" + SID;
Connection conn = DriverManager.getConnection(URL, user, password);
String SQL = "SELECT * from em ";
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(SQL);
while (rs.next()) {
System.out.println(
rs.getString(1) +
"\t" +
rs.getString(2)
);
}
stat.close();
conn.close();
}
}