Handy wsadmin commands:
I feel jacl is much easier than jython :) . Hence here are the jacl commands
To list the installed applications:
/opt/websphere/profile1/bin/wsadmin.sh -conntype SOAP -port 8880 -username wsadmin -c '$AdminApp list'
To Uninstall the Application:
/opt/websphere/profile1/bin/wsadmin.sh -conntype SOAP -port 8880 -username wsadmin -c '$AdminApp uninstall application-xyz'
To backup the existing application:
/opt/websphere/profile1/bin/wsadmin.sh -conntype SOAP -port 8880 -username wsadmin -c '$AdminApp export utilities /tmp/utilities_backup.ear'
To Stop the application:
/opt/websphere/profile1/bin/wsadmin.sh -conntype SOAP -port 8880 -username wsadmin
wsadmin>set appManager [$AdminControl queryNames type=ApplicationManager,*]
WebSphere:name=ApplicationManager,process=xyz,platform=dynamicproxy,node=xyz,version=6.1.0.0,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=xyz,spec=1.0
wsadmin>$AdminApp list
x1
x2
wsadmin>$AdminControl invoke $appManager stopApplication x1
To Start the application:
/opt/websphere/profile1/bin/wsadmin.sh -conntype SOAP -port 8880 -username wsadmin
wsadmin>set appManager [$AdminControl queryNames type=ApplicationManager,*]
WebSphere:name=ApplicationManager,process=xyz,platform=dynamicproxy,node=xyz,version=6.1.0.0,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=xyz,spec=1.0
wsadmin>$AdminApp list
x1
x2
wsadmin>$AdminControl invoke $appManager startApplication x1
To Restart all the application:
Run this command to stop all of the running applications:
foreach app $apps {set appName [$AdminControl getAttribute $app name];
$AdminControl invoke $appManager stopApplication $appName}
Run this command to start all of the running applications:
foreach app $apps {set appName [$AdminControl getAttribute $app name];
$AdminControl invoke $appManager startApplication $appName}
Tuesday, September 21, 2010
Tuesday, September 14, 2010
JRockit - Understanding Threads and Locks
Understanding Threads and Locks
A running application is usually made up of one process with its own memory space. A computer is generally running several processes at the same time. For example, a word processor application process might be running alongside a media player application process. Furthermore, a process consists of many concurrently running threads. When you run a Java application, a new JVM process is started.
Each Java process has at least one application thread. Besides the threads of the running Java application, there are also Oracle JRockit JVM internal threads that take care of garbage collection or code generation.
This section contains basic information about threads and locks in the JRockit JVM. The following subjects are discussed:
* Understanding Threads
* Understanding Locks
For information about how to make so-called thread dumps, printouts of the stacks of all the threads in an application, see Using Thread Dumps. Thread dumps can be used to diagnose problems and optimize application and JVM performance.
Understanding Threads
A java application consists of one or more threads that run Java code. The entire JVM process consists of the Java threads and some JVM internal threads, for example one or more garbage collection threads, a code optimizer thread and one or more finalizer threads.
From the operating system’s point of view the Java threads are just like any application threads. Scheduling of the threads is handled by the operating system, as well as thread priorities.
Within Java, the Java threads are represented by thread objects. Each thread also has a stack, used for storing runtime data. The thread stack has a specific size. If a thread tries to store more items on the stack than the stack size allows, the thread will throw a stack overflow error.
Default Stack Size for Java Threads
This section lists the default stack sizes. You can change the thread stack size with the -Xss command line option, for example:
java -Xss:512k MyApplication
The default stack sizes differ depending upon whether you are using IA32 and X64, as shown
OS Default Stack Size
Windows IA32 64 kB
Windows IA64 320 KB
Windows x64 128 kB
Linux IA32 128 kB
Linux IA64 1024 KB
Linux x64 256 kB
Solaris/SPARC 512 KB
Default Stack Size for JVM Internal Threads
A special “system” stack size is used for JVM internal threads; for example, the garbage collection and code generation threads. The default system stack size is 256 KB on all platforms.
Note: The -Xss command line option sets the stack size of both application threads and JVM internal threads.
Understanding Locks
When threads in a process share and update the same data, their activities must be synchronized to avoid errors. In Java, this is done with the synchronized keyword, or with wait and notify. Synchronization is achieved by the use of locks, each of which is associated with an object by the JVM. For a thread to work on an object, it must have control over the lock associated with it, it must “hold” the lock. Only one thread can hold a lock at a time. If a thread tries to take a lock that is already held by another thread, then it must wait until the lock is released. When this happens, there is so called “contention” for the lock.
There are four different kinds of locks:
* Fat locks: A fat lock is a lock with a history of contention (several threads trying to take the lock simultaneously), or a lock that has been waited on (for notification).
* Thin locks: A thin lock is a lock that does not have any contention.
* Recursive locks: A recursive lock is a lock that has been taken by a thread several times without having been released.
* Lazy locks: A lazy lock is a lock that is not released when a critical section is exited. Once a lazy lock is acquired by a thread, other threads that try to acquire the lock have to ensure that the lock is, or can be, released. Lazy locks are used by default in Oracle JRockit JVM 27.6. In older releases, lazy locks are only used if you have started the JVM with the -XXlazyUnlocking option.
A thin lock can be inflated to a fat lock and a fat lock can be deflated to a thin lock. The JRockit JVM uses a complex set of heuristics to determine when to inflate a thin lock to a fat lock and when to deflate a fat lock to a thin lock.
Spinning and Sleeping
Spinning occurs when a thread that wants a specific lock continuously checks that lock to see if it is still taken, instead of yielding CPU-time to another thread.
Alternatively, a thread that tries to take a lock that is already held waits for notification from the lock and goes into a sleeping state. The thread will then wait passively for the lock to be released.
Lock Chains
Several threads can be tied up in what is called lock chains. Although they appear somewhat complex, lock chains are fairly straightforward. They can be defined as follows:
* Threads A and B form a lock chain if thread A holds a lock that thread B is trying to take. If A is not trying to take a lock, then the lock chain is “open.”
* If A->B is a lock chain, and B->C is a lock chain, then A->B->C is a more complete lock chain.
* If there is no additional thread waiting for a lock held by C, then A->B->C is a complete and open lock chain.
Lock Chain Types
The JRockit JVM analyzes the threads and forms complete lock chains. There are three possible kinds of lock chains: Open, Deadlocked and Blocked lock chains.
Open Chains
Open lock chains represent a straight dependency, thread A is waiting for B which is waiting for C, and so on. If you have long open lock chains, your application might be wasting time waiting for locks. You may then want to reconsider how locks are used for synchronization in your application.
Deadlock Chains
A deadlocked, or circular, lock chain consists of a chain of threads, in which the first thread in the chain is waiting for the last thread in the chain. In the simplest case, thread A is waiting for thread B, while thread B is waiting for thread A. Note that a deadlocked chain has no head. In thread dumps, the Oracle JRockit JVM selects an arbitrary thread to display as the first thread in the chain.
Deadlocks can never be resolved, and the application will be stuck waiting indefinitely.
Blocked Chains
A blocked lock chain is made up of a lock chain whose head thread is also part of another lock chain, which can be either open or deadlocked. For example, if thread A is waiting for thread B, thread B is waiting for thread A, and thread C is waiting for thread A, then thread A and B form a deadlocked lock chain, while thread C and thread A form a blocked lock chain.
Nice Doc from Oracle
A running application is usually made up of one process with its own memory space. A computer is generally running several processes at the same time. For example, a word processor application process might be running alongside a media player application process. Furthermore, a process consists of many concurrently running threads. When you run a Java application, a new JVM process is started.
Each Java process has at least one application thread. Besides the threads of the running Java application, there are also Oracle JRockit JVM internal threads that take care of garbage collection or code generation.
This section contains basic information about threads and locks in the JRockit JVM. The following subjects are discussed:
* Understanding Threads
* Understanding Locks
For information about how to make so-called thread dumps, printouts of the stacks of all the threads in an application, see Using Thread Dumps. Thread dumps can be used to diagnose problems and optimize application and JVM performance.
Understanding Threads
A java application consists of one or more threads that run Java code. The entire JVM process consists of the Java threads and some JVM internal threads, for example one or more garbage collection threads, a code optimizer thread and one or more finalizer threads.
From the operating system’s point of view the Java threads are just like any application threads. Scheduling of the threads is handled by the operating system, as well as thread priorities.
Within Java, the Java threads are represented by thread objects. Each thread also has a stack, used for storing runtime data. The thread stack has a specific size. If a thread tries to store more items on the stack than the stack size allows, the thread will throw a stack overflow error.
Default Stack Size for Java Threads
This section lists the default stack sizes. You can change the thread stack size with the -Xss command line option, for example:
java -Xss:512k MyApplication
The default stack sizes differ depending upon whether you are using IA32 and X64, as shown
OS Default Stack Size
Windows IA32 64 kB
Windows IA64 320 KB
Windows x64 128 kB
Linux IA32 128 kB
Linux IA64 1024 KB
Linux x64 256 kB
Solaris/SPARC 512 KB
Default Stack Size for JVM Internal Threads
A special “system” stack size is used for JVM internal threads; for example, the garbage collection and code generation threads. The default system stack size is 256 KB on all platforms.
Note: The -Xss command line option sets the stack size of both application threads and JVM internal threads.
Understanding Locks
When threads in a process share and update the same data, their activities must be synchronized to avoid errors. In Java, this is done with the synchronized keyword, or with wait and notify. Synchronization is achieved by the use of locks, each of which is associated with an object by the JVM. For a thread to work on an object, it must have control over the lock associated with it, it must “hold” the lock. Only one thread can hold a lock at a time. If a thread tries to take a lock that is already held by another thread, then it must wait until the lock is released. When this happens, there is so called “contention” for the lock.
There are four different kinds of locks:
* Fat locks: A fat lock is a lock with a history of contention (several threads trying to take the lock simultaneously), or a lock that has been waited on (for notification).
* Thin locks: A thin lock is a lock that does not have any contention.
* Recursive locks: A recursive lock is a lock that has been taken by a thread several times without having been released.
* Lazy locks: A lazy lock is a lock that is not released when a critical section is exited. Once a lazy lock is acquired by a thread, other threads that try to acquire the lock have to ensure that the lock is, or can be, released. Lazy locks are used by default in Oracle JRockit JVM 27.6. In older releases, lazy locks are only used if you have started the JVM with the -XXlazyUnlocking option.
A thin lock can be inflated to a fat lock and a fat lock can be deflated to a thin lock. The JRockit JVM uses a complex set of heuristics to determine when to inflate a thin lock to a fat lock and when to deflate a fat lock to a thin lock.
Spinning and Sleeping
Spinning occurs when a thread that wants a specific lock continuously checks that lock to see if it is still taken, instead of yielding CPU-time to another thread.
Alternatively, a thread that tries to take a lock that is already held waits for notification from the lock and goes into a sleeping state. The thread will then wait passively for the lock to be released.
Lock Chains
Several threads can be tied up in what is called lock chains. Although they appear somewhat complex, lock chains are fairly straightforward. They can be defined as follows:
* Threads A and B form a lock chain if thread A holds a lock that thread B is trying to take. If A is not trying to take a lock, then the lock chain is “open.”
* If A->B is a lock chain, and B->C is a lock chain, then A->B->C is a more complete lock chain.
* If there is no additional thread waiting for a lock held by C, then A->B->C is a complete and open lock chain.
Lock Chain Types
The JRockit JVM analyzes the threads and forms complete lock chains. There are three possible kinds of lock chains: Open, Deadlocked and Blocked lock chains.
Open Chains
Open lock chains represent a straight dependency, thread A is waiting for B which is waiting for C, and so on. If you have long open lock chains, your application might be wasting time waiting for locks. You may then want to reconsider how locks are used for synchronization in your application.
Deadlock Chains
A deadlocked, or circular, lock chain consists of a chain of threads, in which the first thread in the chain is waiting for the last thread in the chain. In the simplest case, thread A is waiting for thread B, while thread B is waiting for thread A. Note that a deadlocked chain has no head. In thread dumps, the Oracle JRockit JVM selects an arbitrary thread to display as the first thread in the chain.
Deadlocks can never be resolved, and the application will be stuck waiting indefinitely.
Blocked Chains
A blocked lock chain is made up of a lock chain whose head thread is also part of another lock chain, which can be either open or deadlocked. For example, if thread A is waiting for thread B, thread B is waiting for thread A, and thread C is waiting for thread A, then thread A and B form a deadlocked lock chain, while thread C and thread A form a blocked lock chain.
Nice Doc from Oracle
Thursday, September 9, 2010
Plumb the IP Address (ifconfig)
'ifconfig -a' that will show you all your ports and there name, netmask and everything else you could need to knwo about the card/port.
output :
lo0: flags=1000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843 mtu 1500 index 2
inet 163.37.178.200 netmask ffffffe0 broadcast 163.37.178.223
ether 8:0:20:aa:45:f3
[ If executed as normal user, except the "ether" information
U will get the rest as stated above]
Interpretation from above output :
(a) lo0 & hme0 are the interface names
lo0 is for internal network, hme0 is for external network
(b) numbers given after "inet" are the IP Addresses
for the corresponding Interface
(c) address specified after "ether" is the MAC/Ethernet
address for the Interface Card (only for external cards)
(d) similarly netmask & broadcast addresses are specified
So run a 'ifocnfig -a' the first result will always be 'le0' or 'lo0' forget about that one. Never worry about that. Say you got a quad fast ether net card. You'll then have 4 more results after that. Say hme0 hme1 hme2 hme3, there's your 4 ports you can use (hmex is a example could be qfex or whatever).
Say you want to change hme2 from 192.168.0.1 with netmask of 255.255.0.0 to 192.165.0.1 with a netmask of 255.255.255.0 then you would type the follow command.
ifconfig hme2 plumb up 192.165.0.1 netmask 255.255.255.0
That will change the port. I perfer to unplumb the port first to make sure the above command will work.
Ok so a full set of commands I would type to make the above changes would be.
ifconfig hme2 unplumb (this will bring down port hme2 so it's not used any more)
ifconfig -a (just to make sure the port is no longer used)
ifconfig hme2 plumb up 192.165.0.1 netmask 255.255.255.0 (this will bring port hme2 up with the IP address of 192.165.0.1 and a netmask of 255.255.255.0)
ifconfig -a (just to confirm the changes)
output :
lo0: flags=1000849
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843
inet 163.37.178.200 netmask ffffffe0 broadcast 163.37.178.223
ether 8:0:20:aa:45:f3
[ If executed as normal user, except the "ether" information
U will get the rest as stated above]
Interpretation from above output :
(a) lo0 & hme0 are the interface names
lo0 is for internal network, hme0 is for external network
(b) numbers given after "inet" are the IP Addresses
for the corresponding Interface
(c) address specified after "ether" is the MAC/Ethernet
address for the Interface Card (only for external cards)
(d) similarly netmask & broadcast addresses are specified
So run a 'ifocnfig -a' the first result will always be 'le0' or 'lo0' forget about that one. Never worry about that. Say you got a quad fast ether net card. You'll then have 4 more results after that. Say hme0 hme1 hme2 hme3, there's your 4 ports you can use (hmex is a example could be qfex or whatever).
Say you want to change hme2 from 192.168.0.1 with netmask of 255.255.0.0 to 192.165.0.1 with a netmask of 255.255.255.0 then you would type the follow command.
ifconfig hme2 plumb up 192.165.0.1 netmask 255.255.255.0
That will change the port. I perfer to unplumb the port first to make sure the above command will work.
Ok so a full set of commands I would type to make the above changes would be.
ifconfig hme2 unplumb (this will bring down port hme2 so it's not used any more)
ifconfig -a (just to make sure the port is no longer used)
ifconfig hme2 plumb up 192.165.0.1 netmask 255.255.255.0 (this will bring port hme2 up with the IP address of 192.165.0.1 and a netmask of 255.255.255.0)
ifconfig -a (just to confirm the changes)
Apache Installation on Linux ( Compile)
Download and Install Apache 2.2
Download apache from the Apache 2.2 http://httpd.apache.org/download.cgi#apache22
Look for the section with the phrase "best available version" like "Apache HTTP Server (httpd) 2.2.x is the best available version". At the time of writing this tutorial Apache 2.2.16 is the official best available version.
Click on the link for "httpd-2.2.16.tar.gz" and download the installer.
Once the file is copied on the Linux server (example: /usr/local/install).
1. Use the following command to extract the tar file.
cd /usr/local/install
tar -xzf httpd-2.2.16.tar.gz
A directory will be created "httpd-2.2.16"
2. Now, Let`s execute the configuration script:
cd /usr/local/install/httpd-2.2.16
./configure --prefix=/usr/local/install/apache --enable-mods-shared=all --enable-proxy --enable-expires --enable-vhost-alias
or
./configure --prefix=/usr/local/install/apache --enable-so --with-mpm=worker --enable-proxy=share --enable-ssl --enable-proxy --enable-rewrite --enable-headers --enable-deflate --enable-proxy-http --enable-proxy-balancer --enable-proxy-ajp --enable-expires --enable-usertrack
3. The following steps will compile Apache based upon the configuration defined:
make
4. The following step will install the Apache build:
make install
5. Use the following commands to control the Apache Web Server.
/usr/local/install/apache/bin/apachectl -k stop
/usr/local/install/apache/bin/apachectl -k start
6. Go to the internet browser and try the url http://host:80/.
You should see, It Works!
This means, the Apache webserver installation went successful.
Download apache from the Apache 2.2 http://httpd.apache.org/download.cgi#apache22
Look for the section with the phrase "best available version" like "Apache HTTP Server (httpd) 2.2.x is the best available version". At the time of writing this tutorial Apache 2.2.16 is the official best available version.
Click on the link for "httpd-2.2.16.tar.gz" and download the installer.
Once the file is copied on the Linux server (example: /usr/local/install).
1. Use the following command to extract the tar file.
cd /usr/local/install
tar -xzf httpd-2.2.16.tar.gz
A directory will be created "httpd-2.2.16"
2. Now, Let`s execute the configuration script:
cd /usr/local/install/httpd-2.2.16
./configure --prefix=/usr/local/install/apache --enable-mods-shared=all --enable-proxy --enable-expires --enable-vhost-alias
or
./configure --prefix=/usr/local/install/apache --enable-so --with-mpm=worker --enable-proxy=share --enable-ssl --enable-proxy --enable-rewrite --enable-headers --enable-deflate --enable-proxy-http --enable-proxy-balancer --enable-proxy-ajp --enable-expires --enable-usertrack
3. The following steps will compile Apache based upon the configuration defined:
make
4. The following step will install the Apache build:
make install
5. Use the following commands to control the Apache Web Server.
/usr/local/install/apache/bin/apachectl -k stop
/usr/local/install/apache/bin/apachectl -k start
6. Go to the internet browser and try the url http://host:80/.
You should see, It Works!
This means, the Apache webserver installation went successful.
Tuesday, September 7, 2010
Simple Script to check if file exists and invoke a operation
#Script to check the file and invoke other script
#Author- Satish Kumar
#ver 1.0
#!/bin/bash
HOME=/opt/apps/RAM
FILENAME=$HOME/DRDM_ETL.complete
if [ -e $FILENAME ]
then
cd $HOME
echo Invoking the script at `date '+%F_%H:%M'` >> DRDM_ETL.status
/opt/apps/scripts/invoke.sh
echo Removing the $FILENAME at date '+%F_%H:%M'` >> DRDM_ETL.status
rm $FILENAME
else
echo data file does not exist
fi
#Author- Satish Kumar
#ver 1.0
#!/bin/bash
HOME=/opt/apps/RAM
FILENAME=$HOME/DRDM_ETL.complete
if [ -e $FILENAME ]
then
cd $HOME
echo Invoking the script at `date '+%F_%H:%M'` >> DRDM_ETL.status
/opt/apps/scripts/invoke.sh
echo Removing the $FILENAME at date '+%F_%H:%M'` >> DRDM_ETL.status
rm $FILENAME
else
echo data file does not exist
fi
Subscribe to:
Posts (Atom)