Everybody handling a Unix operating system would very well know what chmod 777 means. That the owner, group and the user of the file is given all permissions (Read, Write and Execute on a particular file). This could otherwise be written as “chmod ugo+rwx “. Meaning that you are giving User, Group and Owner of the file, the rights to Read, Write and Execute the file.
Here comes the rws scenario. Best example that is available for this rws is /usr/bin/passwd command (just issue a “ls -l /usr/bin/passwd”) .
Normally, any user is allowed change HIS password. Meaning he can make an entry or change HIS entry in the /etc/passwd file. But he can never be given ‘WRITE’ permissions on the file because he might end up disturbing other person’s password too. Only a ROOT user is allowed permissions on the /etc/passwd file.
This is where the “rws” comes to picture. When we give “rws” permission to the /usr/bin/passwd command, Unix would assume that the command is executed by the ROOT user. (the user doesnt have permissions on the /etc/passwd file but the root user has). Root user (RWS) permissions could be given on a file as chmod 4700 .
arun@arun-desktop:~/Desktop$ chmod 4700 hi.txt
arun@arun-desktop:~/Desktop$ ls -l hi.txt
-rws—— 1 arun arun 0 2007-01-17 06:48 hi.txt
If you need to act as a group user of a file and not a normal user when executing a particular command (as against the root user) then user “chmod 2700 ”
arun@arun-desktop:~/Desktop$ chmod 2700 hi.txt
arun@arun-desktop:~/Desktop$ ls -l hi.txt
-rwx–S— 1 arun arun 0 2007-01-17 06:48 hi.txt
The 4 and 2 in the front of the chmod commands are called as SUID and SGID bits.
What if we put a 1 instead of 4 and 2 (chmod 1700 ).
arun@arun-desktop:~/Desktop$ chmod 1700 hi.txt
arun@arun-desktop:~/Desktop$ ls -l hi.txt
-rwx—–T 1 arun arun 0 2007-01-17 06:48 hi.txt
It shows a “T” in the place of “x” for a normal user. This “T” bit is called as the Sticky bit.
“When the sticky bit is turned on for a directory users can have read and/or write permissions for that directory, but they can only remove or rename files that they own. The sticky bit on a file tells the operating system that the file will be executed frequently. Files like this are kept in swap space even when they aren’t being executed. Although this takes up swap space it greatly reduces the time it takes to execute the program. Some programs such as vi have the sticky bit turned on by default on some Unixes.”
Thursday, August 26, 2010
Monday, August 9, 2010
OReilly Books
Looks like this site is offering OReilly Books in chm and pdf format online.
http://www.ibreakyoufix.com/tools/books/OReilly/
http://www.ibreakyoufix.com/tools/books/OReilly/
Friday, August 6, 2010
To verify if TRACE is enabled/disabled for Apache Webserver
After TRACE has been disabled according to the instructions mentioned in my thread, a TRACE request will be responded to with HTTP status code 403 (FORBIDDEN).
Using telnet to verify the configuration for a non-SSL web server port
The telnet command provided with most operating systems can be used to verify that the configuration changes to disable TRACE have been made. Note that telnet can only be used to test non-SSL ports, since it does not have the capability to perform the SSL handshake or to encrypt the data.
$ telnet 127.0.0.1 8080
Trying...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
A: b
C: d
Host: foo
HTTP/1.1 403 Forbidden
Date: Mon, 04 Oct 2004 14:23:31 GMT
Server: IBM_HTTP_SERVER
Connection: close
Content-Type: text/html; charset=iso-8859-1
403 Forbidden
You don't have permission to access /
on this server.
Using telnet to verify the configuration for a non-SSL web server port
The telnet command provided with most operating systems can be used to verify that the configuration changes to disable TRACE have been made. Note that telnet can only be used to test non-SSL ports, since it does not have the capability to perform the SSL handshake or to encrypt the data.
$ telnet 127.0.0.1 8080
Trying...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
A: b
C: d
Host: foo
HTTP/1.1 403 Forbidden
Date: Mon, 04 Oct 2004 14:23:31 GMT
Server: IBM_HTTP_SERVER
Connection: close
Content-Type: text/html; charset=iso-8859-1
Forbidden
You don't have permission to access /
on this server.
Connection closed.
The information sent by the client is no longer echoed, and the request fails with HTTP status code 403.
If the response to the TRACE request continues to result in a response with status code 200, verify that the required directives were added to all
Installing Apache with SSL
This article outlines the steps followed while installing the Apache Web Server using the SSL technology. This was done much earlier but steps remain the same.
Installation of Apache and SSL (Requires OpenSSL > openssl-0.9.5a or better. www.openssl.com).
1. Download the latest Apache Webserver from: http://httpd.apache.org/dist/httpd/apache_1.3.19.tar.gz
2. tar zxvf apache_1.3.19.tar.gz
3. Download the latest apache+ssl source from: ftp://opensores.thebunker.net/pub/mirrors/apachessl/apache_1.3.9+ssl_1.42.tar.gz
4. mv apache_1.3.9+ssl_1.42.tar.gz apache_1.3.19
5. tar zxvf apache_1.3.9+ssl_1.42.tar.gz
6. Run the executable: ./FixPatch
7. ./configure --prefix=/usr/local/apache * ./configure -help to get other config time options as needed.
8. make
9. su -
10. make install
11. ln -s /usr/local/apache/conf/httpsd.conf /usr/local/apache/conf/httpd.conf
12. cd /usr/local/apache ; mkdir certs
13. cd certs
14. openssl genrsa -des3 -out ssl.key 1024 -days 365
Remember the PEM password you choose! This command will create ssl.key -days 365 means you will have to do steps 14 & 16 again in 365 days
15. At his point, you are going to create a self-signed Certificate for your site. If you will be using a CA ( Certifying Authority ) Certificate, please review http://www.linuxdoc.org/HOWTO/SSL-RedHat-HOWTO-3.html#ss3.2
16. What is very important to remember in creating the the ssl.crt file is deciding "what is the URL people enter to come to my web site? ". For example, if you own blah.com, and you define blah.com when creating the ssl.crt key, then people who access your site via www.blah.com will get a "Certificate Name Check" that might scare people away because it contains a ominous warning. People who access your site via http://blah.com will not get this warning. However you choose to name your server that is how you must define ServerName in the section below.
17. openssl req -new -key ssl.key -x509 -out ssl.crt Enter your PEM; this will create ssl.crt
This is the Information you will be presented with when issuing this command:
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:South Carolina
Locality Name (eg, city) []:West Columbia
Organization Name (eg,company) [Internet Widgits Pty Ltd]:Michael Sharp
Organizational Unit Name (eg, section) []:Secure Web Server
Common Name (eg, your name or your server's hostname) []:reality.dynip.com
Email Address []:msharp@medmail.com
The Common Name portion is where you define what I was talking about in 15.
18. edit /usr/local/apache/conf/httpsd.conf and at the bottom, under add this:
SSLDisable
EXAMPLE:
SSLCacheServerPort logs/gcache_port
SSLCacheServerPath bin/gcache
SSLSessionCacheTimeout 10
SSLVerifyClient 0
SSLVerifyDepth 10
SSLCacheServerRunDir /tmp
SSLFakeBasicAuth
SSLRandomFile /dev/random 1024
DocumentRoot /usr/local/apache/htdocs ServerName www.CHANGE-THIS.com
ServerAdmin SOMEONE@SOMEWHERE.COM
ErrorLog /usr/local/apache/logs/httpsd_error.log TransferLog /usr/local/apache/logs/httpsd_access.log SSLEnable
SSLCertificateFile /usr/local/apache/certs/ssl.crt SSLCertificateKeyFile /usr/local/apache/certs/ssl.key
You must also comment out Document Root, ServerName, ServerAdmin, ErrorLog, and TransferLog in the Main Server configuration:
#DocumentRoot
#ServerName
#ErrorLog
#ServerAdmin
#TransferLog
Where you see:
# Port: The port to which the standalone server listens. For
# ports < 1023, you will need httpd to be run as root initially.
#
Port 8080
change 8080 to 443
Add any other configuration variables to the httpsd.conf file per your needs.
19. Start the Server:
/usr/local/apache/bin/httpsdctl start
You will have to issue your PEM to start the web server! Don't panic just because it doesn't start immediately give it a few moments.
20. Check out: https://YOUR-WEB-SITE to review if you were successful.
21. Now add your content to /usr/local/apache/htdocs
Virtual Hosts
Virtual hosts enable you to intelligently run multiple sites on a single server. The useful side effect is that with proper setup, you can point your browser to www.whatever.whatever and load a local copy. My development site is now www.mezzoblue.dev, which works exactly the same as the .com, just faster.
Find your httpd.conf file, and then add this line somewhere near the bottom (there’s a spot with example virtual server code)
NameVirtualHost 127.0.0.1
You might want to run a search for ‘NameVirtualHost’ within the file before-hand to make sure it’s not already set, or at least commented out with a preceding octothorpe (#).
Next add an entry for localhost pointing to the root of your web server, so that typing localhost in your browser’s address bar continues pulling up the default site:
ServerName localhost
DocumentRoot /Path/To/WebRoot
And finally, for each individual virtual site you wish to run, add a new entry pointing to the proper directory. This is especially useful because, at least on Unix-based systems, this means it can sit anywhere in your filesystem.
ServerName www.mezzoblue.dev
DocumentRoot /Volumes/Shine/www/delhi
Installation of Apache and SSL (Requires OpenSSL > openssl-0.9.5a or better. www.openssl.com).
1. Download the latest Apache Webserver from: http://httpd.apache.org/dist/httpd/apache_1.3.19.tar.gz
2. tar zxvf apache_1.3.19.tar.gz
3. Download the latest apache+ssl source from: ftp://opensores.thebunker.net/pub/mirrors/apachessl/apache_1.3.9+ssl_1.42.tar.gz
4. mv apache_1.3.9+ssl_1.42.tar.gz apache_1.3.19
5. tar zxvf apache_1.3.9+ssl_1.42.tar.gz
6. Run the executable: ./FixPatch
7. ./configure --prefix=/usr/local/apache * ./configure -help to get other config time options as needed.
8. make
9. su -
10. make install
11. ln -s /usr/local/apache/conf/httpsd.conf /usr/local/apache/conf/httpd.conf
12. cd /usr/local/apache ; mkdir certs
13. cd certs
14. openssl genrsa -des3 -out ssl.key 1024 -days 365
Remember the PEM password you choose! This command will create ssl.key -days 365 means you will have to do steps 14 & 16 again in 365 days
15. At his point, you are going to create a self-signed Certificate for your site. If you will be using a CA ( Certifying Authority ) Certificate, please review http://www.linuxdoc.org/HOWTO/SSL-RedHat-HOWTO-3.html#ss3.2
16. What is very important to remember in creating the the ssl.crt file is deciding "what is the URL people enter to come to my web site? ". For example, if you own blah.com, and you define blah.com when creating the ssl.crt key, then people who access your site via www.blah.com will get a "Certificate Name Check" that might scare people away because it contains a ominous warning. People who access your site via http://blah.com will not get this warning. However you choose to name your server that is how you must define ServerName in the
17. openssl req -new -key ssl.key -x509 -out ssl.crt Enter your PEM; this will create ssl.crt
This is the Information you will be presented with when issuing this command:
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:South Carolina
Locality Name (eg, city) []:West Columbia
Organization Name (eg,company) [Internet Widgits Pty Ltd]:Michael Sharp
Organizational Unit Name (eg, section) []:Secure Web Server
Common Name (eg, your name or your server's hostname) []:reality.dynip.com
Email Address []:msharp@medmail.com
The Common Name portion is where you define what I was talking about in 15.
18. edit /usr/local/apache/conf/httpsd.conf and at the bottom, under
SSLDisable
SSLCacheServerPort logs/gcache_port
SSLCacheServerPath bin/gcache
SSLSessionCacheTimeout 10
SSLVerifyClient 0
SSLVerifyDepth 10
SSLCacheServerRunDir /tmp
SSLFakeBasicAuth
SSLRandomFile /dev/random 1024
DocumentRoot /usr/local/apache/htdocs ServerName www.CHANGE-THIS.com
ServerAdmin SOMEONE@SOMEWHERE.COM
ErrorLog /usr/local/apache/logs/httpsd_error.log TransferLog /usr/local/apache/logs/httpsd_access.log SSLEnable
SSLCertificateFile /usr/local/apache/certs/ssl.crt SSLCertificateKeyFile /usr/local/apache/certs/ssl.key
You must also comment out Document Root, ServerName, ServerAdmin, ErrorLog, and TransferLog in the Main Server configuration:
#DocumentRoot
#ServerName
#ErrorLog
#ServerAdmin
#TransferLog
Where you see:
# Port: The port to which the standalone server listens. For
# ports < 1023, you will need httpd to be run as root initially.
#
Port 8080
change 8080 to 443
Add any other configuration variables to the httpsd.conf file per your needs.
19. Start the Server:
/usr/local/apache/bin/httpsdctl start
You will have to issue your PEM to start the web server! Don't panic just because it doesn't start immediately give it a few moments.
20. Check out: https://YOUR-WEB-SITE to review if you were successful.
21. Now add your content to /usr/local/apache/htdocs
Virtual Hosts
Virtual hosts enable you to intelligently run multiple sites on a single server. The useful side effect is that with proper setup, you can point your browser to www.whatever.whatever and load a local copy. My development site is now www.mezzoblue.dev, which works exactly the same as the .com, just faster.
Find your httpd.conf file, and then add this line somewhere near the bottom (there’s a spot with example virtual server code)
NameVirtualHost 127.0.0.1
You might want to run a search for ‘NameVirtualHost’ within the file before-hand to make sure it’s not already set, or at least commented out with a preceding octothorpe (#).
Next add an entry for localhost pointing to the root of your web server, so that typing localhost in your browser’s address bar continues pulling up the default site:
ServerName localhost
DocumentRoot /Path/To/WebRoot
And finally, for each individual virtual site you wish to run, add a new entry pointing to the proper directory. This is especially useful because, at least on Unix-based systems, this means it can sit anywhere in your filesystem.
ServerName www.mezzoblue.dev
DocumentRoot /Volumes/Shine/www/delhi
Handy Unix and linux commands
####################################################################
Finding CPU Information:
Solaris: /usr/platform/sun4u/sbin/prtdiag | grep 'System Configuration' | sed 's/.*(\\(.*\\) .*)/\\1/'
Linux: cat /proc/cpuinfo | grep '^model name' | sed 's/.*: //'
####################################################################
CPU Speed:
Solaris: psrinfo -v | grep MHz | awk '{print $6 $7}'
Linux: cat /proc/cpuinfo | grep '^cpu MHz' | sed 's/.*: //'
####################################################################
total Disk Space:
Solaris: /usr/sbin/df -kF ufs | grep -v Filesystem | awk '{print $2,$6}'
Linux: /bin/df -kl -x tmpfs | grep -v Filesystem | awk '{print $2,$6}'
####################################################################
Total Physical Memory
Solaris: /usr/sbin/prtconf | grep Memory | sed 's/.*: //' | awk '{print $1*1024}'
Linux: cat /proc/meminfo | grep '^MemTotal' | sed 's/.*: //' | awk '{print $1}'
####################################################################
echo $?
result of last command... 0 success and 1 failure
####################################################################
Send mail as an attachment with subject as "Logs"
uuencode log log | mailx -s "Logs" username@domain.com
####################################################################
find command with different options
find . -name "*.log" -type f -print -exec -mtime +7 gzip {} \ ; finding files with *.log and checking if older than 7 days and gzipping them
find . -name "*.log" -mtime +7 -exec rm -rf {} \; finding *.log and checking if older than 7 days and removing them
find . -size +1000m -exec ls -ltr {} \;
####################################################################
Command to clear Semaphore and Shared memory
Clear Semaphore : ipcs|grep ^s|awk '{print "ipcrm -s " $2}'|sh
Clear Shared memory : ipcs|grep ^m|awk '{print "ipcrm -m " $2}'|sh
Check semaphore and shared memory: ipcs
####################################################################
screen -S backup -t backup
screen -d -r pid.backup
####################################################################
tar cf - dir/ | gzip -c > file.tar.gz
####################################################################
kill all the httpd process
ps -ef | grep httpd | sed -e '/grep/d' | awk '{print $2}'|xargs kill -9
####################################################################
Simple for loop to check the remote hostname and output of the command
for i in a b c; do ssh apache@server${i}col "echo \"Host: server${i}col\";ls -ltr /tmp";done
####################################################################
Command to check Processor 32 or 64 bit
Solaris: isainfo -b
Linux : uname -a
x86_64 and ia64 are 64 bit , if i386 is 32 bit
####################################################################
###################################################
AIX command to check machine name.
###################################################
/opt/local/bin/nmon -r -t
###################################################
AIX command to check CPU name.
###################################################
topas
vmstat --- for memory
###################################################
Command to check WLM on AIX
###################################################
smitty
wlmstat
Finding CPU Information:
Solaris: /usr/platform/sun4u/sbin/prtdiag | grep 'System Configuration' | sed 's/.*(\\(.*\\) .*)/\\1/'
Linux: cat /proc/cpuinfo | grep '^model name' | sed 's/.*: //'
####################################################################
CPU Speed:
Solaris: psrinfo -v | grep MHz | awk '{print $6 $7}'
Linux: cat /proc/cpuinfo | grep '^cpu MHz' | sed 's/.*: //'
####################################################################
total Disk Space:
Solaris: /usr/sbin/df -kF ufs | grep -v Filesystem | awk '{print $2,$6}'
Linux: /bin/df -kl -x tmpfs | grep -v Filesystem | awk '{print $2,$6}'
####################################################################
Total Physical Memory
Solaris: /usr/sbin/prtconf | grep Memory | sed 's/.*: //' | awk '{print $1*1024}'
Linux: cat /proc/meminfo | grep '^MemTotal' | sed 's/.*: //' | awk '{print $1}'
####################################################################
echo $?
result of last command... 0 success and 1 failure
####################################################################
Send mail as an attachment with subject as "Logs"
uuencode log log | mailx -s "Logs" username@domain.com
####################################################################
find command with different options
find . -name "*.log" -type f -print -exec -mtime +7 gzip {} \ ; finding files with *.log and checking if older than 7 days and gzipping them
find . -name "*.log" -mtime +7 -exec rm -rf {} \; finding *.log and checking if older than 7 days and removing them
find . -size +1000m -exec ls -ltr {} \;
####################################################################
Command to clear Semaphore and Shared memory
Clear Semaphore : ipcs|grep ^s|awk '{print "ipcrm -s " $2}'|sh
Clear Shared memory : ipcs|grep ^m|awk '{print "ipcrm -m " $2}'|sh
Check semaphore and shared memory: ipcs
####################################################################
screen -S backup -t backup
screen -d -r pid.backup
####################################################################
tar cf - dir/ | gzip -c > file.tar.gz
####################################################################
kill all the httpd process
ps -ef | grep httpd | sed -e '/grep/d' | awk '{print $2}'|xargs kill -9
####################################################################
Simple for loop to check the remote hostname and output of the command
for i in a b c; do ssh apache@server${i}col "echo \"Host: server${i}col\";ls -ltr /tmp";done
####################################################################
Command to check Processor 32 or 64 bit
Solaris: isainfo -b
Linux : uname -a
x86_64 and ia64 are 64 bit , if i386 is 32 bit
####################################################################
###################################################
AIX command to check machine name.
###################################################
/opt/local/bin/nmon -r -t
###################################################
AIX command to check CPU name.
###################################################
topas
vmstat --- for memory
###################################################
Command to check WLM on AIX
###################################################
smitty
wlmstat
Websphere - What you want to know about HTTP session persistence
. With Web 2.0 technologies taking off, more and more Web applications are being redesigned, and as they get changed, these same questions come up even more frequently. If you are involved in redesigning any Web applications for Web 2.0, here are answers to some of the questions you might soon be asking.
1. If I don’t need session persistence, can I turn it off?
Yes, you can configure session management to run with in-memory sessions, which is actually the default. You can still use HttpSessions in this mode, but if a failure occurs, the data stored in the HttpSessions will be lost.
2. What are the session persistence options with WebSphere® Application Server Network Deployment, and what are the advantages and disadvantages of each?
The two main options for HttpSession are database persistence and memory to memory replication. SipSession replication only can use the memory to memory replication. In IBM® WebSphere Application Server Network Deployment, memory to memory replication uses what is called the data replication service (DRS). Additionally, the ObjectGrid (OG) feature of IBM WebSphere eXtreme Scale also offers memory to memory replication for HttpSession.
* Database persistence is the most widely-used option. The performance of database persistence is also better than memory to memory replication, when not taking the extra hardware that the database is running on into account. Another advantage is that this solution can handle cascading failures of application servers, which is only possible with more than one replica in a memory to memory configuration. The disadvantage of database persistence is the cost of the database, particularly if the session data stored in the database should itself be highly available.
* The DRS memory to memory solution is a good solution for many deployments. DRS is "best effort" memory to memory replication, which performs slightly worse than database persistence, depending on data size and number of sessions. The primary advantage of DRS is that you avoid the cost of the database. The disadvantage of DRS is that it is less reliable than the other options. Although we say that DRS is "best effort" and sessions might be lost in the event of a failure, the chances of session loss are minimal in a properly tuned system.
* The third option is the OG memory to memory solution. The advantage of this solution is that it provides everything from asynchronous replication that is not best effort to guaranteed synchronous transactional replication. It is also less expensive than most database solutions. The primary disadvantage would be the added cost above WebSphere Application Server Network Deployment, even though this is less than most database license costs.
3. If I need to come up with a one-size-fits-all general architecture, which do I choose?
In my opinion, I would start with database persistence and investigate OG memory to memory persistence to reduce database costs. Database persistence is the most commonly used architecture and it performs the best.
4. Under what conditions can data be lost?
The most common scenario for session loss is when the write frequency is set to something like time-based writes. Any changes in the session between the last write and a server failure can be lost. This applies to any session replication options.
As I pointed out above, DRS has only a slight chance of losing a session because it is best effort. We say that DRS is best effort because it has no acknowledgements to ensure the data is received by the backup system, and in a system that has congestion issues, a session might not get replicated at all. When the high availability management system in WebSphere Application Server gets very busy, a failure to send the session might occur. While DRS will attempt to retry the send of the session, it might eventually fail if the congestion still exists with each retry. The number of retries and the retry interval is configurable. In the end, you might lose a session if a heavy workload causes these congestion failures for eac h initial try and for the retries, and if the server with that session fails. In this case, the session will be lost and the application will need to handle such a scenario.
The important thing to understand about DRS is that under non-failure conditions, the session will always be there. When a failure does occur, data that has not been written out before the failure occurred might be lost, regardless of whether the server is using database or DRS persistence. If this is a problem for a specific application, you might consider using something like the ObjectGrid cache instead of the session to store those objects. ObjectGrid provides transactional semantics around the object to ensure that if a failure occurs, you know when the change has been committed so that, if the error occurred before the change is committed, you can roll back.
5. Will a loss of session affect any of the other WebSphere Application Server components?
Some parts of the application server itself depend on session to store state like JavaServer™ Faces (JSF) widgets. When a session is lost, however, those pieces are able to recover with some notable problems. For example, if a tree JSF widget was expanded to a certain section and a failure occurs, the next refreshed view of that tree might no longer be expanded.
6. What are other recommendations for using sessions that will be persisted?
* Keep the session state small, preferably less than 4K overall.
* Use transient variables when possible, particularly when caching items in the session. A transient variable enables the application to keep a copy in local memory, but rebuilds the object if using the backup copy.
* Consider using an object cache like WebSphere eXtreme Scale rather than using the session for caching. While sessions might be convenient, the APIs are not purposed as a cache and do not meet many of the needs you could encounter with an object cache.
7. Should I use a single row or multi-row schema with database persistence?
A single row schema provides fewer database queries overall and pushes more data to the database with each update. However, a multi-row schema can be more efficient -- or even necessary -- when there are large session attributes or very few changes to the attributes. Larger amounts of data can be stored using these multi-row schemas since each attribute is stored in its own row in the database. However, the resulting performance can be worse with a multi-row schema, since gathering attributes out of the session might cause multiple queries.
8. What tuning parameters are available for HttpSession in WebSphere Application Server Network Deployment?
The major session tuning options are outlined in the WebSphere Application Server Information Center. For HttpSession, a good place to begin tuning is the write frequency. Basically, you can configure how often the session manager writes to the database or to the peer server’s memory. The best performing options will perform the writes less frequently via the time-based options. The worst performing options are at the end of servlet service method (when the servlet returns from whatever method it was called through) or the manual update (where the servlet itself calls a method on the IBMSession object to cause the write to happen). The manual update can be the most efficient means of session persistence if the attributes are infrequently updated. However, they do introduce the potential for the application failing to call the sync method on the IBMSession after having updated the attribute.
The next major piece to change would be the "write contents," or the options as to what the session manager will write out. Those options consist of whether to write all the session attributes out to the persistence mechanism, or to write just the updated attributes. Writing all of the attributes out each time should really never be done. Aside from the performance not being as good as writing out just the updated attributes, it also can hurt portability to other platforms. Some servers do not support anything but the basic requirement, which is to persist the attribute when a setAttribute method is called.
1. If I don’t need session persistence, can I turn it off?
Yes, you can configure session management to run with in-memory sessions, which is actually the default. You can still use HttpSessions in this mode, but if a failure occurs, the data stored in the HttpSessions will be lost.
2. What are the session persistence options with WebSphere® Application Server Network Deployment, and what are the advantages and disadvantages of each?
The two main options for HttpSession are database persistence and memory to memory replication. SipSession replication only can use the memory to memory replication. In IBM® WebSphere Application Server Network Deployment, memory to memory replication uses what is called the data replication service (DRS). Additionally, the ObjectGrid (OG) feature of IBM WebSphere eXtreme Scale also offers memory to memory replication for HttpSession.
* Database persistence is the most widely-used option. The performance of database persistence is also better than memory to memory replication, when not taking the extra hardware that the database is running on into account. Another advantage is that this solution can handle cascading failures of application servers, which is only possible with more than one replica in a memory to memory configuration. The disadvantage of database persistence is the cost of the database, particularly if the session data stored in the database should itself be highly available.
* The DRS memory to memory solution is a good solution for many deployments. DRS is "best effort" memory to memory replication, which performs slightly worse than database persistence, depending on data size and number of sessions. The primary advantage of DRS is that you avoid the cost of the database. The disadvantage of DRS is that it is less reliable than the other options. Although we say that DRS is "best effort" and sessions might be lost in the event of a failure, the chances of session loss are minimal in a properly tuned system.
* The third option is the OG memory to memory solution. The advantage of this solution is that it provides everything from asynchronous replication that is not best effort to guaranteed synchronous transactional replication. It is also less expensive than most database solutions. The primary disadvantage would be the added cost above WebSphere Application Server Network Deployment, even though this is less than most database license costs.
3. If I need to come up with a one-size-fits-all general architecture, which do I choose?
In my opinion, I would start with database persistence and investigate OG memory to memory persistence to reduce database costs. Database persistence is the most commonly used architecture and it performs the best.
4. Under what conditions can data be lost?
The most common scenario for session loss is when the write frequency is set to something like time-based writes. Any changes in the session between the last write and a server failure can be lost. This applies to any session replication options.
As I pointed out above, DRS has only a slight chance of losing a session because it is best effort. We say that DRS is best effort because it has no acknowledgements to ensure the data is received by the backup system, and in a system that has congestion issues, a session might not get replicated at all. When the high availability management system in WebSphere Application Server gets very busy, a failure to send the session might occur. While DRS will attempt to retry the send of the session, it might eventually fail if the congestion still exists with each retry. The number of retries and the retry interval is configurable. In the end, you might lose a session if a heavy workload causes these congestion failures for eac h initial try and for the retries, and if the server with that session fails. In this case, the session will be lost and the application will need to handle such a scenario.
The important thing to understand about DRS is that under non-failure conditions, the session will always be there. When a failure does occur, data that has not been written out before the failure occurred might be lost, regardless of whether the server is using database or DRS persistence. If this is a problem for a specific application, you might consider using something like the ObjectGrid cache instead of the session to store those objects. ObjectGrid provides transactional semantics around the object to ensure that if a failure occurs, you know when the change has been committed so that, if the error occurred before the change is committed, you can roll back.
5. Will a loss of session affect any of the other WebSphere Application Server components?
Some parts of the application server itself depend on session to store state like JavaServer™ Faces (JSF) widgets. When a session is lost, however, those pieces are able to recover with some notable problems. For example, if a tree JSF widget was expanded to a certain section and a failure occurs, the next refreshed view of that tree might no longer be expanded.
6. What are other recommendations for using sessions that will be persisted?
* Keep the session state small, preferably less than 4K overall.
* Use transient variables when possible, particularly when caching items in the session. A transient variable enables the application to keep a copy in local memory, but rebuilds the object if using the backup copy.
* Consider using an object cache like WebSphere eXtreme Scale rather than using the session for caching. While sessions might be convenient, the APIs are not purposed as a cache and do not meet many of the needs you could encounter with an object cache.
7. Should I use a single row or multi-row schema with database persistence?
A single row schema provides fewer database queries overall and pushes more data to the database with each update. However, a multi-row schema can be more efficient -- or even necessary -- when there are large session attributes or very few changes to the attributes. Larger amounts of data can be stored using these multi-row schemas since each attribute is stored in its own row in the database. However, the resulting performance can be worse with a multi-row schema, since gathering attributes out of the session might cause multiple queries.
8. What tuning parameters are available for HttpSession in WebSphere Application Server Network Deployment?
The major session tuning options are outlined in the WebSphere Application Server Information Center. For HttpSession, a good place to begin tuning is the write frequency. Basically, you can configure how often the session manager writes to the database or to the peer server’s memory. The best performing options will perform the writes less frequently via the time-based options. The worst performing options are at the end of servlet service method (when the servlet returns from whatever method it was called through) or the manual update (where the servlet itself calls a method on the IBMSession object to cause the write to happen). The manual update can be the most efficient means of session persistence if the attributes are infrequently updated. However, they do introduce the potential for the application failing to call the sync method on the IBMSession after having updated the attribute.
The next major piece to change would be the "write contents," or the options as to what the session manager will write out. Those options consist of whether to write all the session attributes out to the persistence mechanism, or to write just the updated attributes. Writing all of the attributes out each time should really never be done. Aside from the performance not being as good as writing out just the updated attributes, it also can hurt portability to other platforms. Some servers do not support anything but the basic requirement, which is to persist the attribute when a setAttribute method is called.
MQSC commands / mqsc command reference / ibm mqsc commands
The MQSC commands
==================
This section describes, in alphabetic order, all the MQSC commands that can be issued by operators and administrators.
* ALTER AUTHINFO
Use the MQSC command ALTER AUTHINFO to alter an authentication information object. Start of changeThese objects contain the definitions required to perform certificate revocation checking using OCSP or Certificate Revocation Lists (CRLs) on LDAP servers.End of change
* ALTER BUFFPOOL
Use the MQSC command ALTER BUFFPOOL to dynamically add buffers to a predefined buffer pool, or remove buffers from a predefined buffer pool.
* ALTER CFSTRUCT
Use the MQSC command ALTER CFSTRUCT to alter the CF application structure backup and recovery parameters for any specified application structure.
* ALTER CHANNEL
Use the MQSC command ALTER CHANNEL to alter the parameters of a channel.
* ALTER LISTENER
Use MQSC command ALTER LISTENER to alter the parameters of an existing WebSphere® MQ listener definition. If the listener is already running, any changes you make to its definition are effective only after the next time that the listener is started.
* ALTER NAMELIST
Use the MQSC command ALTER NAMELIST to alter a list of names. This is most commonly a list of cluster names or queue names.
* ALTER PROCESS
Use the MQSC command ALTER PROCESS to alter the parameters of an existing WebSphere MQ process definition.
* ALTER PSID
Use the MQSC command ALTER PSID to change the expansion method for a page set.
* ALTER QMGR
Use the MQSC command ALTER QMGR to alter the queue manager parameters for the local queue manager.
* ALTER queues
Use the MQSC command ALTER command to alter the parameters of a local queue (ALTER QLOCAL), alias queue (ALTER QALIAS), model queue (ALTER QMODEL), a remote queue, a queue-manager alias, or a reply-to queue alias (ALTER QREMOTE).
* ALTER SECURITY
Use the MQSC command ALTER SECURITY to define system-wide security options.
* ALTER SERVICE
Use the MQSC command ALTER SERVICE to alter the parameters of an existing WebSphere MQ service definition.
* ALTER STGCLASS
Use the MQSC command ALTER STGCLASS to alter the characteristics of a storage class.
* ALTER SUB
Use the MQSC command ALTER SUB to alter the characteristics of an existing subscription.
* ALTER TOPIC
Use ALTER TOPIC to alter the parameters of an existing WebSphere MQ topic object.
* ALTER TRACE
Use the MQSC command ALTER TRACE to change the trace events being traced for a particular active queue manager trace. ALTER TRACE stops the specified trace, and restarts it with the altered parameters.
* ARCHIVE LOG
Use the MQSC command ARCHIVE LOG as part of your backup procedure. It takes a copy of the current active log (or both logs if you are using dual logging).
* BACKUP CFSTRUCT
Use the MQSC command BACKUP CFSTRUCT to initiate a CF application structure backup.
* CLEAR QLOCAL
Use the MQSC command CLEAR QLOCAL to clear the messages from a local queue.
* CLEAR TOPICSTR
Use the MQSC command CLEAR TOPICSTR to clear the retained message which is stored for the specified topic string.
* DEFINE AUTHINFO
Use the MQSC command DEFINE AUTHINFO to define an authentication information object. Start of changeThese objects contain the definitions required to perform certificate revocation checking using OCSP or Certificate Revocation Lists (CRLs) on LDAP servers.End of change
* DEFINE BUFFPOOL
Use the MQSC command DEFINE BUFFPOOL to define a buffer pool that is used for holding messages in main storage.
* DEFINE CFSTRUCT
Use the MQSC command DEFINE CFSTRUCT to define queue manager CF level capability, and backup and recovery parameters for a Coupling Facility application structure.
* DEFINE CHANNEL
Use the MQSC command DEFINE CHANNEL to define a new channel, and set its parameters.
* DEFINE LISTENER
Use the MQSC command DEFINE LISTENER to define a new WebSphere MQ listener definition, and set its parameters.
* DEFINE LOG
Use the MQSC command DEFINE LOG to add a new active log data set in the ring of active logs.
* DEFINE MAXSMSGS
Use the MQSC command DEFINE MAXSMSGS to define the maximum number of messages that a task can get or put within a single unit of recovery.
* DEFINE NAMELIST
Use the MQSC command DEFINE NAMELIST to define a list of names. This is most commonly a list of cluster names or queue names.
* DEFINE PROCESS
Use the MQSC command DEFINE PROCESS to define a new WebSphere MQ process definition, and set its parameters.
* DEFINE PSID
Use the MQSC command DEFINE PSID to define a page set and associated buffer pool.
* DEFINE QUEUE
* DEFINE SERVICE
Use the MQSC command DEFINE SERVICE to define a new WebSphere MQ service definition, and set its parameters.
* DEFINE STGCLASS
Use the MQSC command DEFINE STGCLASS to define a storage class to page set mapping.
* DEFINE SUB
Use DEFINE SUB to allow an existing application to participate in a publish/subscribe application by allowing the administrative creation of a subscription.
* DEFINE TOPIC
Use DEFINE TOPIC to define a new WebSphere MQ administrative topic node in a topic tree, and set its parameters.
* DELETE AUTHINFO
Use MQSC command DELETE AUTHINFO to delete an authentication information object.
* DELETE BUFFPOOL
Use the MQSC command DELETE BUFFPOOL to delete a buffer pool that is used for holding messages in main storage.
* DELETE CFSTRUCT
Use the MQSC command DELETE CFSTRUCT to delete a CF application structure definition.
* DELETE CHANNEL
Use the MQSC command DELETE CHANNEL to delete a channel definition.
* DELETE LISTENER
Use the MQSC command DELETE LISTENER to delete a listener definition.
* DELETE NAMELIST
Use the MQSC command DELETE NAMELIST to delete a namelist definition.
* DELETE PROCESS
Use the MQSC command DELETE PROCESS to delete a process definition.
* DELETE PSID
Use the MQSC command DELETE PSID to delete a page set. This command closes the page set and de-allocates it from the queue manager.
* DELETE queues
* DELETE SERVICE
Use the MQSC command DELETE SERVICE to delete a service definition.
* DELETE SUB
Use the MQSC command DELETE SUB to remove a durable subscription from the system. For a managed destination, any unprocessed messages left on the destination are removed.
* DELETE STGCLASS
Use the MQSC command DELETE STGCLASS to delete a storage class definition.
* DELETE TOPIC
Use DELETE TOPIC to delete a WebSphere MQ administrative topic node.
* DISPLAY ARCHIVE
Use the MQSC command DISPLAY ARCHIVE to display archive system parameters and information.
* DISPLAY AUTHINFO
Use the MQSC command DISPLAY AUTHINFO to display the attributes of an authentication information object.
* DISPLAY CFSTATUS
Use the MQSC command DISPLAY CFSTATUS to display the status of one or more CF application structures. This command is valid only on WebSphere MQ for z/OS® when the queue manager is a member of a queue-sharing group.
* DISPLAY CFSTRUCT
Use the MQSC command DISPLAY CFSTRUCT to display the attributes of one or more CF application structures. This command is valid only on z/OS when the queue manager is a member of a queue-sharing group.
* DISPLAY CHANNEL
Use the MQSC command DISPLAY CHANNEL to display a channel definition.
* DISPLAY CHINIT
Use the MQSC command DISPLAY CHINIT to display information about the channel initiator. The command server must be running.
* DISPLAY CHSTATUS
Use the MQSC command DISPLAY CHSTATUS to display the status of one or more channels.
* DISPLAY CLUSQMGR
Use the MQSC command DISPLAY CLUSQMGR to display information about cluster channels for queue managers in a cluster.
* DISPLAY CMDSERV
Use the MQSC command DISPLAY CMDSERV to display the status of the command server.
* DISPLAY CONN
Use the MQSC command DISPLAY CONN to display connection information about the applications connected to the queue manager. This is a useful command because it enables you to identify applications with long-running units of work.
* DISPLAY GROUP
Use the MQSC command DISPLAY GROUP to display information about the queue-sharing group to which the queue manager is connected. This command is valid only when the queue manager is a member of a queue-sharing group.
* DISPLAY LISTENER
Use the MQSC command DISPLAY LISTENER to display information about a listener.
* DISPLAY LOG
Use the MQSC command DISPLAY LOG to display log system parameters and information.
* DISPLAY LSSTATUS
Use the MQSC command DISPLAY LSSTATUS to display status information for one or more listeners.
* DISPLAY MAXSMSGS
Use the MQSC command DISPLAY MAXSMSGS to see the maximum number of messages that a task can get or put within a single unit of recovery.
* DISPLAY NAMELIST
Use the MQSC command DISPLAY NAMELIST to display the names in a namelist.
* DISPLAY PROCESS
Use the MQSC command DISPLAY PROCESS to display the attributes of one or more WebSphere MQ processes.
* DISPLAY PUBSUB
Use the MQSC command DISPLAY PUBSUB to display publish/subscribe status information for a queue manager.
* DISPLAY QMGR
Use the MQSC command DISPLAY QMGR to display the queue manager parameters for this queue manager.
* DISPLAY QMSTATUS
Use the MQSC command DISPLAY QMSTATUS to display status information associated with this queue manager.
* DISPLAY QSTATUS
Use the MQSC command DISPLAY QSTATUS to display the status of one or more queues.
* DISPLAY QUEUE
Use the MQSC command DISPLAY QUEUE to display the attributes of one or more queues of any type.
* DISPLAY SBSTATUS
Use the MQSC command DISPLAY SBSTATUS to display the status of a subscription.
* DISPLAY SECURITY
Use the MQSC command DISPLAY SECURITY to display the current settings for the security parameters.
* DISPLAY SERVICE
Use the MQSC command DISPLAY SERVICE to display information about a service.
* DISPLAY STGCLASS
Use the MQSC command DISPLAY STGCLASS to display information about storage classes.
* DISPLAY SUB
Use the MQSC command DISPLAY SUB to display the attributes associated with a subscription.
* DISPLAY SVSTATUS
Use the MQSC command DISPLAY SVSTATUS to display status information for one or more services.
* DISPLAY SYSTEM
Use the MQSC command DISPLAY SYSTEM to display general system parameters and information.
* DISPLAY THREAD
Use the MQSC command DISPLAY THREAD to display information about active and in-doubt threads.
* DISPLAY TOPIC
Use the MQSC command DISPLAY TOPIC to display the attributes of one or more WebSphere MQ topic objects of any type.
* DISPLAY TPSTATUS
Use the MQSC command DISPLAY TPSTATUS to display the status of one or more topic nodes in a topic tree.
* DISPLAY TRACE
Use the MQSC command DISPLAY TRACE to display a list of active traces.
* DISPLAY USAGE
Use the MQSC command DISPLAY USAGE to display information about the current state of a page set, or to display information about the log data sets.
* MOVE QLOCAL
Use the MQSC command MOVE QLOCAL to move all the messages from one local queue to another.
* PING CHANNEL
Use the MQSC command PING CHANNEL to test a channel by sending data as a special message to the remote queue manager, and checking that the data is returned. The data is generated by the local queue manager.
* PING QMGR
Use the MQSC command PING QMGR to test whether the queue manager is responsive to commands.
* RECOVER BSDS
Use the MQSC command RECOVER BSDS to reestablish a dual bootstrap data set (BSDS) after one has been disabled by a data set error.
* RECOVER CFSTRUCT
Use the MQSC command RECOVER CFSTRUCT to initiate recovery of CF application structures. This command is valid only when the queue manager is a member of a queue-sharing group.
* REFRESH CLUSTER
Use the MQSC command REFRESH CLUSTER to discard all locally held cluster information (including any autodefined channels that are in doubt), and force it to be rebuilt. This enables you to perform a "cold-start" on the cluster.
* REFRESH QMGR
Use the MQSC command REFRESH QMGR to perform special operations on queue managers.
* REFRESH SECURITY
Use the MQSC command REFRESH SECURITY to perform a security refresh.
* RESET CHANNEL
Use the MQSC command RESET CHANNEL to reset the message sequence number for a WebSphere MQ channel with, optionally, a specified sequence number to be used the next time that the channel is started.
* RESET CLUSTER
Use the MQSC command RESET CLUSTER to perform special operations on clusters.
* RESET QMGR
Use the MQSC command RESET QMGR as part of your backup and recovery procedures.
* RESET QSTATS
Use the MQSC command RESET QSTATS to report performance data for a queue and then to reset that data.
* RESET TPIPE
Use the MQSC command RESET TPIPE to reset the recoverable sequence numbers for an IMS™ Tpipe used by the WebSphere MQ-IMS bridge.
* RESOLVE CHANNEL
Use the MQSC command RESOLVE CHANNEL to request a channel to commit or back out in-doubt messages.
* RESOLVE INDOUBT
Use the MQSC command RESOLVE INDOUBT to resolve threads left in doubt because WebSphere MQ or a transaction manager could not resolve them automatically.
* RESUME QMGR
Use the MQSC command RESUME QMGR to inform other queue mangers in a cluster that the local queue manager is available again for processing and can be sent messages. It reverses the action of the SUSPEND QMGR command.
* RVERIFY SECURITY
Use the MQSC command RVERIFY SECURITY to set a reverification flag for all specified users. The user is reverified the next time that security is checked for that user.
* SET ARCHIVE
Use the MQSC command SET ARCHIVE to dynamically change certain archive system parameter values initially set by your system parameter module at queue manager startup.
* SET LOG
Use the MQSC command SET LOG to dynamically change certain log system parameter values that were initially set by your system parameter module at queue manager startup.
* SET SYSTEM
Use the MQSC command SET SYSTEM to dynamically change certain general system parameter values that were initially set from your system parameter module at queue manager startup.
* START CHANNEL
Use the MQSC command START CHANNEL to start a channel.
* START CHINIT
Use the MQSC command START CHINIT to start a channel initiator.
* START CMDSERV
Use the MQSC command START CMDSERV to initialize the command server.
* START LISTENER
Use the MQSC command START LISTENER to start a channel listener.
* START QMGR
Use the MQSC command START QMGR to initialize the queue manager.
* START SERVICE
Use the MQSC command START SERVICE to start a service. The identified service definition is started within the queue manager and inherits the environment and security variables of the queue manager.
* START TRACE
Use the MQSC command START TRACE to start traces.
* STOP CHANNEL
Use the MQSC command STOP CHANNEL to stop a channel.
* STOP CHINIT
Use the MQSC command STOP CHINIT to stop a channel initiator. The command server must be running.
* STOP CMDSERV
Use the MQSC command STOP CMDSERV to stop the command server.
* STOP CONN
Use the MQSC command STOP CONN to break a connection between an application and the queue manager.
* STOP LISTENER
Use the MQSC command STOP LISTENER to stop a channel listener.
* STOP QMGR
Use the MQSC command STOP QMGR to stop the queue manager.
* STOP SERVICE
Use the MQSC command STOP SERVICE to stop a service.
* STOP TRACE
Use the MQSC command STOP TRACE to stop tracing.
* SUSPEND QMGR
Use the MQSC command SUSPEND QMGR to inform other queue managers in a cluster that the local queue manager is not available for processing and cannot be sent messages, or to suspend logging and update activity for the queue manager until a subsequent RESUME QMGR command is issued. Its action can be reversed by the RESUME QMGR command.
==================
This section describes, in alphabetic order, all the MQSC commands that can be issued by operators and administrators.
* ALTER AUTHINFO
Use the MQSC command ALTER AUTHINFO to alter an authentication information object. Start of changeThese objects contain the definitions required to perform certificate revocation checking using OCSP or Certificate Revocation Lists (CRLs) on LDAP servers.End of change
* ALTER BUFFPOOL
Use the MQSC command ALTER BUFFPOOL to dynamically add buffers to a predefined buffer pool, or remove buffers from a predefined buffer pool.
* ALTER CFSTRUCT
Use the MQSC command ALTER CFSTRUCT to alter the CF application structure backup and recovery parameters for any specified application structure.
* ALTER CHANNEL
Use the MQSC command ALTER CHANNEL to alter the parameters of a channel.
* ALTER LISTENER
Use MQSC command ALTER LISTENER to alter the parameters of an existing WebSphere® MQ listener definition. If the listener is already running, any changes you make to its definition are effective only after the next time that the listener is started.
* ALTER NAMELIST
Use the MQSC command ALTER NAMELIST to alter a list of names. This is most commonly a list of cluster names or queue names.
* ALTER PROCESS
Use the MQSC command ALTER PROCESS to alter the parameters of an existing WebSphere MQ process definition.
* ALTER PSID
Use the MQSC command ALTER PSID to change the expansion method for a page set.
* ALTER QMGR
Use the MQSC command ALTER QMGR to alter the queue manager parameters for the local queue manager.
* ALTER queues
Use the MQSC command ALTER command to alter the parameters of a local queue (ALTER QLOCAL), alias queue (ALTER QALIAS), model queue (ALTER QMODEL), a remote queue, a queue-manager alias, or a reply-to queue alias (ALTER QREMOTE).
* ALTER SECURITY
Use the MQSC command ALTER SECURITY to define system-wide security options.
* ALTER SERVICE
Use the MQSC command ALTER SERVICE to alter the parameters of an existing WebSphere MQ service definition.
* ALTER STGCLASS
Use the MQSC command ALTER STGCLASS to alter the characteristics of a storage class.
* ALTER SUB
Use the MQSC command ALTER SUB to alter the characteristics of an existing subscription.
* ALTER TOPIC
Use ALTER TOPIC to alter the parameters of an existing WebSphere MQ topic object.
* ALTER TRACE
Use the MQSC command ALTER TRACE to change the trace events being traced for a particular active queue manager trace. ALTER TRACE stops the specified trace, and restarts it with the altered parameters.
* ARCHIVE LOG
Use the MQSC command ARCHIVE LOG as part of your backup procedure. It takes a copy of the current active log (or both logs if you are using dual logging).
* BACKUP CFSTRUCT
Use the MQSC command BACKUP CFSTRUCT to initiate a CF application structure backup.
* CLEAR QLOCAL
Use the MQSC command CLEAR QLOCAL to clear the messages from a local queue.
* CLEAR TOPICSTR
Use the MQSC command CLEAR TOPICSTR to clear the retained message which is stored for the specified topic string.
* DEFINE AUTHINFO
Use the MQSC command DEFINE AUTHINFO to define an authentication information object. Start of changeThese objects contain the definitions required to perform certificate revocation checking using OCSP or Certificate Revocation Lists (CRLs) on LDAP servers.End of change
* DEFINE BUFFPOOL
Use the MQSC command DEFINE BUFFPOOL to define a buffer pool that is used for holding messages in main storage.
* DEFINE CFSTRUCT
Use the MQSC command DEFINE CFSTRUCT to define queue manager CF level capability, and backup and recovery parameters for a Coupling Facility application structure.
* DEFINE CHANNEL
Use the MQSC command DEFINE CHANNEL to define a new channel, and set its parameters.
* DEFINE LISTENER
Use the MQSC command DEFINE LISTENER to define a new WebSphere MQ listener definition, and set its parameters.
* DEFINE LOG
Use the MQSC command DEFINE LOG to add a new active log data set in the ring of active logs.
* DEFINE MAXSMSGS
Use the MQSC command DEFINE MAXSMSGS to define the maximum number of messages that a task can get or put within a single unit of recovery.
* DEFINE NAMELIST
Use the MQSC command DEFINE NAMELIST to define a list of names. This is most commonly a list of cluster names or queue names.
* DEFINE PROCESS
Use the MQSC command DEFINE PROCESS to define a new WebSphere MQ process definition, and set its parameters.
* DEFINE PSID
Use the MQSC command DEFINE PSID to define a page set and associated buffer pool.
* DEFINE QUEUE
* DEFINE SERVICE
Use the MQSC command DEFINE SERVICE to define a new WebSphere MQ service definition, and set its parameters.
* DEFINE STGCLASS
Use the MQSC command DEFINE STGCLASS to define a storage class to page set mapping.
* DEFINE SUB
Use DEFINE SUB to allow an existing application to participate in a publish/subscribe application by allowing the administrative creation of a subscription.
* DEFINE TOPIC
Use DEFINE TOPIC to define a new WebSphere MQ administrative topic node in a topic tree, and set its parameters.
* DELETE AUTHINFO
Use MQSC command DELETE AUTHINFO to delete an authentication information object.
* DELETE BUFFPOOL
Use the MQSC command DELETE BUFFPOOL to delete a buffer pool that is used for holding messages in main storage.
* DELETE CFSTRUCT
Use the MQSC command DELETE CFSTRUCT to delete a CF application structure definition.
* DELETE CHANNEL
Use the MQSC command DELETE CHANNEL to delete a channel definition.
* DELETE LISTENER
Use the MQSC command DELETE LISTENER to delete a listener definition.
* DELETE NAMELIST
Use the MQSC command DELETE NAMELIST to delete a namelist definition.
* DELETE PROCESS
Use the MQSC command DELETE PROCESS to delete a process definition.
* DELETE PSID
Use the MQSC command DELETE PSID to delete a page set. This command closes the page set and de-allocates it from the queue manager.
* DELETE queues
* DELETE SERVICE
Use the MQSC command DELETE SERVICE to delete a service definition.
* DELETE SUB
Use the MQSC command DELETE SUB to remove a durable subscription from the system. For a managed destination, any unprocessed messages left on the destination are removed.
* DELETE STGCLASS
Use the MQSC command DELETE STGCLASS to delete a storage class definition.
* DELETE TOPIC
Use DELETE TOPIC to delete a WebSphere MQ administrative topic node.
* DISPLAY ARCHIVE
Use the MQSC command DISPLAY ARCHIVE to display archive system parameters and information.
* DISPLAY AUTHINFO
Use the MQSC command DISPLAY AUTHINFO to display the attributes of an authentication information object.
* DISPLAY CFSTATUS
Use the MQSC command DISPLAY CFSTATUS to display the status of one or more CF application structures. This command is valid only on WebSphere MQ for z/OS® when the queue manager is a member of a queue-sharing group.
* DISPLAY CFSTRUCT
Use the MQSC command DISPLAY CFSTRUCT to display the attributes of one or more CF application structures. This command is valid only on z/OS when the queue manager is a member of a queue-sharing group.
* DISPLAY CHANNEL
Use the MQSC command DISPLAY CHANNEL to display a channel definition.
* DISPLAY CHINIT
Use the MQSC command DISPLAY CHINIT to display information about the channel initiator. The command server must be running.
* DISPLAY CHSTATUS
Use the MQSC command DISPLAY CHSTATUS to display the status of one or more channels.
* DISPLAY CLUSQMGR
Use the MQSC command DISPLAY CLUSQMGR to display information about cluster channels for queue managers in a cluster.
* DISPLAY CMDSERV
Use the MQSC command DISPLAY CMDSERV to display the status of the command server.
* DISPLAY CONN
Use the MQSC command DISPLAY CONN to display connection information about the applications connected to the queue manager. This is a useful command because it enables you to identify applications with long-running units of work.
* DISPLAY GROUP
Use the MQSC command DISPLAY GROUP to display information about the queue-sharing group to which the queue manager is connected. This command is valid only when the queue manager is a member of a queue-sharing group.
* DISPLAY LISTENER
Use the MQSC command DISPLAY LISTENER to display information about a listener.
* DISPLAY LOG
Use the MQSC command DISPLAY LOG to display log system parameters and information.
* DISPLAY LSSTATUS
Use the MQSC command DISPLAY LSSTATUS to display status information for one or more listeners.
* DISPLAY MAXSMSGS
Use the MQSC command DISPLAY MAXSMSGS to see the maximum number of messages that a task can get or put within a single unit of recovery.
* DISPLAY NAMELIST
Use the MQSC command DISPLAY NAMELIST to display the names in a namelist.
* DISPLAY PROCESS
Use the MQSC command DISPLAY PROCESS to display the attributes of one or more WebSphere MQ processes.
* DISPLAY PUBSUB
Use the MQSC command DISPLAY PUBSUB to display publish/subscribe status information for a queue manager.
* DISPLAY QMGR
Use the MQSC command DISPLAY QMGR to display the queue manager parameters for this queue manager.
* DISPLAY QMSTATUS
Use the MQSC command DISPLAY QMSTATUS to display status information associated with this queue manager.
* DISPLAY QSTATUS
Use the MQSC command DISPLAY QSTATUS to display the status of one or more queues.
* DISPLAY QUEUE
Use the MQSC command DISPLAY QUEUE to display the attributes of one or more queues of any type.
* DISPLAY SBSTATUS
Use the MQSC command DISPLAY SBSTATUS to display the status of a subscription.
* DISPLAY SECURITY
Use the MQSC command DISPLAY SECURITY to display the current settings for the security parameters.
* DISPLAY SERVICE
Use the MQSC command DISPLAY SERVICE to display information about a service.
* DISPLAY STGCLASS
Use the MQSC command DISPLAY STGCLASS to display information about storage classes.
* DISPLAY SUB
Use the MQSC command DISPLAY SUB to display the attributes associated with a subscription.
* DISPLAY SVSTATUS
Use the MQSC command DISPLAY SVSTATUS to display status information for one or more services.
* DISPLAY SYSTEM
Use the MQSC command DISPLAY SYSTEM to display general system parameters and information.
* DISPLAY THREAD
Use the MQSC command DISPLAY THREAD to display information about active and in-doubt threads.
* DISPLAY TOPIC
Use the MQSC command DISPLAY TOPIC to display the attributes of one or more WebSphere MQ topic objects of any type.
* DISPLAY TPSTATUS
Use the MQSC command DISPLAY TPSTATUS to display the status of one or more topic nodes in a topic tree.
* DISPLAY TRACE
Use the MQSC command DISPLAY TRACE to display a list of active traces.
* DISPLAY USAGE
Use the MQSC command DISPLAY USAGE to display information about the current state of a page set, or to display information about the log data sets.
* MOVE QLOCAL
Use the MQSC command MOVE QLOCAL to move all the messages from one local queue to another.
* PING CHANNEL
Use the MQSC command PING CHANNEL to test a channel by sending data as a special message to the remote queue manager, and checking that the data is returned. The data is generated by the local queue manager.
* PING QMGR
Use the MQSC command PING QMGR to test whether the queue manager is responsive to commands.
* RECOVER BSDS
Use the MQSC command RECOVER BSDS to reestablish a dual bootstrap data set (BSDS) after one has been disabled by a data set error.
* RECOVER CFSTRUCT
Use the MQSC command RECOVER CFSTRUCT to initiate recovery of CF application structures. This command is valid only when the queue manager is a member of a queue-sharing group.
* REFRESH CLUSTER
Use the MQSC command REFRESH CLUSTER to discard all locally held cluster information (including any autodefined channels that are in doubt), and force it to be rebuilt. This enables you to perform a "cold-start" on the cluster.
* REFRESH QMGR
Use the MQSC command REFRESH QMGR to perform special operations on queue managers.
* REFRESH SECURITY
Use the MQSC command REFRESH SECURITY to perform a security refresh.
* RESET CHANNEL
Use the MQSC command RESET CHANNEL to reset the message sequence number for a WebSphere MQ channel with, optionally, a specified sequence number to be used the next time that the channel is started.
* RESET CLUSTER
Use the MQSC command RESET CLUSTER to perform special operations on clusters.
* RESET QMGR
Use the MQSC command RESET QMGR as part of your backup and recovery procedures.
* RESET QSTATS
Use the MQSC command RESET QSTATS to report performance data for a queue and then to reset that data.
* RESET TPIPE
Use the MQSC command RESET TPIPE to reset the recoverable sequence numbers for an IMS™ Tpipe used by the WebSphere MQ-IMS bridge.
* RESOLVE CHANNEL
Use the MQSC command RESOLVE CHANNEL to request a channel to commit or back out in-doubt messages.
* RESOLVE INDOUBT
Use the MQSC command RESOLVE INDOUBT to resolve threads left in doubt because WebSphere MQ or a transaction manager could not resolve them automatically.
* RESUME QMGR
Use the MQSC command RESUME QMGR to inform other queue mangers in a cluster that the local queue manager is available again for processing and can be sent messages. It reverses the action of the SUSPEND QMGR command.
* RVERIFY SECURITY
Use the MQSC command RVERIFY SECURITY to set a reverification flag for all specified users. The user is reverified the next time that security is checked for that user.
* SET ARCHIVE
Use the MQSC command SET ARCHIVE to dynamically change certain archive system parameter values initially set by your system parameter module at queue manager startup.
* SET LOG
Use the MQSC command SET LOG to dynamically change certain log system parameter values that were initially set by your system parameter module at queue manager startup.
* SET SYSTEM
Use the MQSC command SET SYSTEM to dynamically change certain general system parameter values that were initially set from your system parameter module at queue manager startup.
* START CHANNEL
Use the MQSC command START CHANNEL to start a channel.
* START CHINIT
Use the MQSC command START CHINIT to start a channel initiator.
* START CMDSERV
Use the MQSC command START CMDSERV to initialize the command server.
* START LISTENER
Use the MQSC command START LISTENER to start a channel listener.
* START QMGR
Use the MQSC command START QMGR to initialize the queue manager.
* START SERVICE
Use the MQSC command START SERVICE to start a service. The identified service definition is started within the queue manager and inherits the environment and security variables of the queue manager.
* START TRACE
Use the MQSC command START TRACE to start traces.
* STOP CHANNEL
Use the MQSC command STOP CHANNEL to stop a channel.
* STOP CHINIT
Use the MQSC command STOP CHINIT to stop a channel initiator. The command server must be running.
* STOP CMDSERV
Use the MQSC command STOP CMDSERV to stop the command server.
* STOP CONN
Use the MQSC command STOP CONN to break a connection between an application and the queue manager.
* STOP LISTENER
Use the MQSC command STOP LISTENER to stop a channel listener.
* STOP QMGR
Use the MQSC command STOP QMGR to stop the queue manager.
* STOP SERVICE
Use the MQSC command STOP SERVICE to stop a service.
* STOP TRACE
Use the MQSC command STOP TRACE to stop tracing.
* SUSPEND QMGR
Use the MQSC command SUSPEND QMGR to inform other queue managers in a cluster that the local queue manager is not available for processing and cannot be sent messages, or to suspend logging and update activity for the queue manager until a subsequent RESUME QMGR command is issued. Its action can be reversed by the RESUME QMGR command.
Memory Utilization of Individual Process on Linux
One of my colleague found this easy way to figure of memory utilization of each process running on linux machine without root access though :)
To calculate for each process on linux we do the following:
We have a java process runing on 7804 . Hence pid is 7804
[test@appsupport /]$ cat /proc/7804/statm
124 123 108 6 1 117 10
[test@appsupport /]$
In this 124 is in pages, to calculate it to KB multiply It with 4 ( 124*4 => 496 KB ).
################
Script to calculate the total memory for n number of processes.
################
Below we are calculating for all root process running.
ps auxwww | grep -i root | awk '{ print $2}' > /tmp/txt.txt
for i in `cat /tmp/txt.txt`; do cd /proc/;cd $i;a=`cat statm | awk '{ print $1}'`; let a*=4; echo $a memory utilized by $i "completed";let b=b+a;cd ../; done
To calculate for each process on linux we do the following:
We have a java process runing on 7804 . Hence pid is 7804
[test@appsupport /]$ cat /proc/7804/statm
124 123 108 6 1 117 10
[test@appsupport /]$
In this 124 is in pages, to calculate it to KB multiply It with 4 ( 124*4 => 496 KB ).
################
Script to calculate the total memory for n number of processes.
################
Below we are calculating for all root process running.
ps auxwww | grep -i root | awk '{ print $2}' > /tmp/txt.txt
for i in `cat /tmp/txt.txt`; do cd /proc/;cd $i;a=`cat statm | awk '{ print $1}'`; let a*=4; echo $a memory utilized by $i "completed";let b=b+a;cd ../; done
Thursday, August 5, 2010
mod_proxy or mod_jk
There are several ways to run Tomcat applications. You can either run tomcat direcly on port 80, or you can put a webserver in front of tomcat and proxy connections to it. I would highly recommend using Apache as a front end. The main reason for this suggestion is that Apache is more flexible than tomcat. Apache has many modules that would require you to code support yourself in Tomcat. For example, while Tomcat can do gzip compression, it's a single switch; enabled or disabled. Sadly you can not compress CSS or javascript for Internet Explorer 6. This is easy to support in Apache, but impossible to do in Tomcat. Things like caching are also easier to do in Apache.
Having decided to use Apache to front Tomcat, you need to decide how to connect them. There are several choices: mod_proxy ( more accurately, mod_proxy_http in Apache 2.2, but I'll refer to this as mod_proxy), mod_jk and mod_jk2. Mod_jk2 is not under active development and should not be used. This leaves us with mod_proxy or mod_jk.
Both methods forward requests from apache to tomcat. mod_proxy uses the HTTP that we all know an love. mod_jk uses a binary protocol AJP. The main advantages of mod_jk are:
- AJP is a binary protocol, so is slightly quicker for both ends to deal with and uses slightly less overhead compared to HTTP, but this is minimal.
- AJP includes information like original host name, the remote host and the SSL connection. This means that ServletRequest.isSecure() works as expected, and that you know who is connecting to you and allows you to do some sort of virtualhosting in your code.
A slight disadvantage is that AJP is based on fixed sized chunks, and can break with long headers, particularly request URLs with long list of parameters, but you should rarely be in a position of having 8K of URL parameters. (It would suggest you were doing it wrong. :) )
It used to be the case that mod_jk provided basic load balancing between two tomcats, which mod_proxy couldn't do, but with the new mod_proxy_balancer in Apache 2.2, this is no longer a reason to choose between them.
The position is slightly complicated by the existence of mod_proxy_ajp. Between them, mod_jk is the more mature of the two, but mod_proxy_ajp works in the same framework as the other mod_proxy modules. I have not yet used mod_proxy_ajp, but would consider doing so in the future, as mod_proxy_ajp is part of Apche and mod_jk involves additional configuration outside of Apache.
Given a choice, I would prefer a AJP based connector, mostly due to my second stated advantage, more than the performance aspect. Of course, if your application vendor doesn't support anything other than mod_proxy_http, that does tie your hands somewhat.
You could use an alternative webserver like lighttpd, which does have an AJP module. Sadly, my prefered lightweight HTTP server, nginx, does not support AJP and is unlike ever to do so, due to the design of its proxying system.
########################################
mod_jk Configuration
########################################
Here's an example of the extra configuartion needed in the Apache httpd configuration file - (/usr/local/apache2/conf/httpd.conf)LoadModule jk_module modules/mod_jk.so
JkWorkersFile /usr/local/apache2/conf/jkworkers.properties
JkMount /latmjdemo* catkin
And here's the jkworkers.properties file:worker.list=catkin
worker.oak.port=8009
worker.oak.host=192.168.200.1
worker.oak.lbfactor=5
worker.elm.port=8009
worker.elm.host=192.168.200.158
worker.elm.lbfactor=15
worker.catkin.type=lb
worker.catkin.balanced_workers=oak,elm
worker.catkin.sticky_session=1
Traffic is forwarded to a Tomcat server called "Oak" on 192.168.200.1, or a Tomcat server called "Elm" on 192.168.200.158, with that latter getting 3 forwards for every one passed to Oak.
The "sticky_session" is worth comment. Rather than randomly forwarding tarffic to either server, httpd will forward users who already have sessions established to the same system right through their session. That way, a multiple page process (such as an on line ordering system) can easily be implemented without the need for a lot of extra code to share work-in-progress data between the various Tomcat server.
In order for sticky sessions to work, you need to configure your jvmRoute in Tomcat to reflect the server name
########################################
########################################
mod_proxy Configuration
########################################
Proxy forwarding to a Java Server
Here's an example of a proxied request from Apache httpd on to a server (probably Apache Tomcat) that's running the ajp protocol on port 5090:ProxyPass /harry ajp://192.168.200.215:5090/latmjdemo
ProxyPassReverse /harry ajp://192.168.200.215:5090/latmjdemo
That's code to be added to the end of your httpd.conf file!
Proxy forwarding to a group of Java Servers
It gets even better ... mod_proxy_balancer lets you define a group of Java servers which you can forward your traffic on to - ideal on a busy site where the background task that's running in Java is a resource hog and needs to be shared between systems. Here's an example of what you would add to httpd.conf:
BalancerMember ajp://192.168.200.215:5090/latmjdemo
BalancerMember ajp://192.168.200.214:5009/latmjdemo
ProxyPass /prince balancer://catbox/
In this example, any references to the web resources on the server under the /prince directory will be forwarded to one of two other machines, on port 5090, and will be directed to the "latmjdemo" web application on there.
More flexibility in forwarding to a group of Servers
The example above uses the default "round robin" scheduler - but there are other facilities available too to help you tune your forwarding. Here's a further example:
BalancerMember ajp://192.168.200.219:5009/latmjdemo loadfactor=1
BalancerMember ajp://192.168.200.218:5009/latmjdemo loadfactor=3
BalancerMember ajp://192.168.200.215:5009/latmjdemo status=+h
ProxySet lbmethod=bytraffic
ProxySet stickysession=JSESSIONID
ProxyPass /corgi balancer://kennel/
In this example, we are forwarding to 2 systems, in a ratio of 1 : 3 and we're allocating traffic based on the traffic quantities coming back from each server rather than the number of requests (so queries that generate a lot of traffic count for more). An extra machine has been designated as "hot swap" if neither of the others is available. Once a visitor is allocated to a particular machine for his forward, he'll continue to be forwarded to that same system while his JSESSIONID cookie remains live.
Some other notes about mod_proxy and family in Apache 2.2:
• ProxyPassMatch is available, which lets you specify a pattern (Regular Expression) for your forwarding - for example, if you wanted to forward all you image requests to an image server:ProxyPassMatch ^/(.*\.jpg)$ http://images.wellho.net/$1
• mod_rewrite IS aware of mod_proxy_balancer, so that you can rewrite your requests as we do in many parts of our site, and then forward them on to other systems through an appropriate balancer.
• As from Apache 2.2.9, ProxyPassReverse is also mod_proxy_balancer aware.
########################################
Subscribe to:
Posts (Atom)