Friday, April 26, 2013

WebLogic Persistent Store

The persistent store provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence. 


For example -> it can store persistent JMS messages or temporarily store messages sent using the Store-and-Forward feature. 


The persistent store supports persistence to a file-based store or to a JDBC-enabled database.


Comparing File Stores and JDBC Stores

The following are some similarities and differences between file stores and JDBC stores:
The default persistent store can only be a file store. A JDBC store cannot be used as a      default persistent store.
-------------------------------------------------------------------------------------
The transaction log (TLOG) can only be stored in a default store.
-------------------------------------------------------------------------------------
Both have the same transaction semantics and guarantees. As with JDBC store writes, file store writes are guaranteed to be persisted to disk and are not simply left in an intermediate (that is, unsafe) cache.
-------------------------------------------------------------------------------------
Both have the same application interface (no difference in application code).
-------------------------------------------------------------------------------------
All things being equal, file stores generally offer better throughput than a JDBC store.
Note: If a database is running on high-end hardware with very fast disks, and WebLogic Server is running on slower hardware or with slower disks, then you may get better performance from the JDBC store.
-------------------------------------------------------------------------------------
File stores are generally easier to configure and administer, and do not require that WebLogic subsystems depend on any external component.
-------------------------------------------------------------------------------------
File stores generate no network traffic; whereas, JDBC stores will generate network traffic if the database is on a different machine from WebLogic Server.
-------------------------------------------------------------------------------------
JDBC stores may make it easier to handle failure recovery since the JDBC interface can access the database from any machine on the same network. With the file store, the disk must be shared or migrated.
-------------------------------------------------------------------------------------
Securing File Store Data
In order to properly secure file store data, you must set appropriate directory permissions on all your file store directories. If you require data encryption, you must use appropriate third-party encryption software.

Default Persistent Store

Each server instance, including the administration server, has a default persistent store that requires no configuration. The default store is a file-based store that maintains its data in a group of files in a server instance's data\store\default directory. A directory for the default store is automatically created if one does not already exist. This default store is available to subsystems that do not require explicit selection of a particular store and function best by using the system's default storage mechanism. For example, a JMS Server with no persistent store configured will use the default store for its Managed Server and will support persistent messaging.
The default store can be configured by directly manipulating the DefaultFileStoreMBean parameters. If this MBean is not defined in the domain's configuration file, then the configuration subsystem ensures that the DefaultFileStoreMBean always exists with the default values.
Also, the Administration Console enables you to change the default store parameters, such as its default directory location and Synchronous Write Policy
Default Store Location
The default store maintains its data in a data\store\default directory inside the servername subdirectory of a domain's root directory
For example, if no directory name is specified for the default file store, it defaults to:
bea_home\user_projects\domains\domain-name\servers\server-name\data\store\default
where domainname is the root directory of your domain, typically c:\bea\user_projects\domains\domainname

WLST : Encrypt the credentials when running WLST in interactive or script mode

If you want to get away from providing user name and password in plain text when using WLST. WebLogic Server provides a way to encrypt the credentials for server start up. You can create a password file "boot.properties" (called as Boot Identity File) with plain text credentials in a folder named security under the server root directory. This file will be automatically detected during the server start up and the server will encrypt the information in this file for subsequent use. Until WebLogic Server 9.x this file should be placed under the DOMAIN folder. So servers sharing the same file system share the same boot identity file and cannot be configured to use different files.
This boot identity file can also be used by WLST only when started from the domain folder. This is mainly because the domain's password key (SerializedSystemIni.dat) is used to encrypt this file. 
If you are using WLST from a different location or from a remote machine to connect to the server or if you want to run WLST script you can use a different technique. You can use WLST to generate a User Configuration file which will have encrypted user name and password using storeUserConfig() command. A key file that will be used to encrypt the data will also get generated along with the user config file. The key file is important as it is required to decrypt the values back from the user config file. This is an online WLST command. So you should be connected to a running WebLogic Server or a Node Manager to issue this command.
When you use this command with no arguments the user configuration file for the current user will be generated within the current OS user's home folder.

wls:/testdomain/serverConfig>storeUserConfig()

You can also specify the location and name for the key file and the userconfig file if you want them to be created elsewhere.
wls:/testdomain/serverConfig>storeUserConfig('/usr/home/user1/configfile.secure', '/usr/home/user1/keyfile.secure')

If the files are stored with the default name (osusername-WebLogicConfig.properties & osusername-WebLogicKey.properties) you can simply connect without specifying the username and password in the connect() command.
wls:/offline> connect(url='t3://host:port')

If the files are stored in a different location or with a different name, then they can be passed as an argument to the connect() command 
wls:/offline> connect(userConfigFile='/usr/home/user1/configfile.secure', userKeyFile='/usr/home/user1/keyfile.secure', url='t3://host:port')
or connect with node manager like below

nmConnect (userConfigFile='/usr/home/user1/configfile.secure',userKeyFile='/usr/home/user1/keyfile.secure',host='HOSTNAME',port='PORT',domainName='DOMAIN_NAME',domainDir='DOMAIN_DIR_PATH',nmType='plain')

Cluster Multicast Messaging and Unicast Messaging Mode

When servers are in a cluster, these member servers communicate with each other by sending heartbeats and indicating that they are alive. 
For this communication between the servers, either unicast or multicast messaging is used. This is chosen from the admin console in Cluster -> Configuration -> Messaging -> Messaging Mode.
To use multicast messaging, hardware configuration and support for multicast packets is required. 
Unicast does not have this requirement, which is why using unicast in latest versions is recommended.
When multicast messaging is used, it is a one-to-many communication, every server sends the notification/heartbeat/multicast packet to each other. This causes a heavy load on the application’s multicast buffer, so if the buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are dropped. So there is a possibility that the server instances miss the messages. This might lead in the cluster throwing out the server instances out of the cluster.
Unicast configuration is much easier because it does not require cross network configuration that multicast requires. Additionally, it reduces potential network errors that can occur from multicast address conflicts.
Mode of Communication:

Multicast – A multicast address and multicast port is used for listening to the messages.
Unicast – A network channel is used for communication between the servers. If no channel is     
             specified, default network channel is used.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Method of communication between servers:

Multicast – Each server communicates with every member server in the cluster. Which means heartbeats are sent to every server.
Unicast - For the member servers in the cluster, group leaders are chosen and only those group leaders communicate with the servers among the group and these leaders notify each other about the availability of all the other servers.
For example : Suppose there are 6 servers in the cluster. 2 groups are made and there are 2 group leaders. Other 2 servers of the group will notify their leader that they are alive and the group leader will send this information to the leader of other group.
The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For new server versions, using unicast is recommended because it is a simplified communication mode. But for backward compatibility with the previous versions, you will need to use multicast if there is a communication requirement between clusters of versions prior to WLS 10.0.
Whenever the messaging mode of the cluster is changed, all the servers in the cluster need a restart because the changes are not dynamic.

Enable Disable Weblogic Admin Console

Enable Disable Weblogic Admin Console

Disable the Console

By default, each time the Administration Server starts it automatically deploys the Administration Console. If you want to prevent access to the Administration Console (for example, as an added security measure in a production environment) you can prevent the Administration Server from deploying it.
To disable access to the Administration Console:
  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit
  2. In the left pane of the Console, under Domain Structure, select the domain name.
  3. Select Configuration > General, and click Advanced at the bottom of the page.
  4. Deselect Console Enabled.
  5. Click Save.
  6. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

Enabling the Administration Console

By default, the Administration Console is enabled. If you disable it, you can re-enable it using the WebLogic Scripting Tool (WLST). Start the Administration Server, then invoke WLST and use the following commands:

connect("username","password")
edit()
startEdit()
cmo.setConsoleEnabled(true)
save()
activate()

The following attribute(s) have been changed on MBeans which require server re-start.

MBean Changed : com.bea:Name=mydomain,Type=Domain Attributes changed :
ConsoleEnabled
Activation completed
disconnect()
exit()

Java HotSpot VM Options

Some Useful -XX Options

 
  • Boolean options are turned on with -XX:+<option> and turned off with -XX:-<option>.
  • Numeric options are set with -XX:<option>=<number>. Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768).
  • String options are set with -XX:<option>=<string>, are usually used to specify a file, a path, or a list of commands

Behavioral Options

Option and Default Value
Description
-XX:-AllowUserSignalHandlers
Do not complain if the application installs signal handlers. (Relevant to Solaris and Linux only.)
-XX:AltStackSize=16384
Alternate signal stack size (in Kbytes). (Relevant to Solaris only, removed from 5.0.)
-XX:-DisableExplicitGC
Disable calls to System.gc(), JVM still performs garbage collection when necessary.
-XX:+FailOverToOldVerifier
Fail over to old verifier when the new type checker fails. (Introduced in 6.)
-XX:+HandlePromotionFailure
The youngest generation collection does not require a guarantee of full promotion of all live objects. (Introduced in 1.4.2 update 11) [5.0 and earlier: false.]
-XX:+MaxFDLimit
Bump the number of file descriptors to max. (Relevant  to Solaris only.)
-XX:PreBlockSpin=10
Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.)
-XX:-RelaxAccessControlCheck
Relax the access control checks in the verifier. (Introduced in 6.)
-XX:+ScavengeBeforeFullGC
Do young generation GC prior to a full GC. (Introduced in 1.4.1.)
-XX:+UseAltSigs
Use alternate signals instead of SIGUSR1 and SIGUSR2 for VM internal signals. (Introduced in 1.3.1 update 9, 1.4.1. Relevant to Solaris only.)
-XX:+UseBoundThreads
Bind user level threads to kernel threads. (Relevant to Solaris only.)
-XX:-UseConcMarkSweepGC
Use concurrent mark-sweep collection for the old generation. (Introduced in 1.4.1)
-XX:+UseGCOverheadLimit
Use a policy that limits the proportion of the VM's time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)
-XX:+UseLWPSynchronization
Use LWP-based instead of thread based synchronization. (Introduced in 1.4.0. Relevant to Solaris only.)
-XX:-UseParallelGC
Use parallel garbage collection for scavenges. (Introduced in 1.4.1)
-XX:-UseParallelOldGC
Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)
-XX:-UseSerialGC
Use serial garbage collection. (Introduced in 5.0.)
-XX:-UseSpinning
Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (Relevant to 1.4.2 and 5.0 only.) [1.4.2, multi-processor Windows platforms: true]
-XX:+UseTLAB
Use thread-local object allocation (Introduced in 1.4.0, known as UseTLE prior to that.) [1.4.2 and earlier, x86 or with -client: false]
-XX:+UseSplitVerifier
Use the new type checker with StackMapTable attributes. (Introduced in 5.0.)[5.0: false]
-XX:+UseThreadPriorities
Use native thread priorities.
-XX:+UseVMInterruptibleIO
Thread interrupt before or with EINTR for I/O operations results in OS_INTRPT. (Introduced in 6. Relevant to Solaris only.)


Performance Options

Option and Default Value
Description
-XX:+AggressiveOpts
Turn on point performance compiler optimizations that are expected to be default in upcoming releases. (Introduced in 5.0 update 6.)
-XX:CompileThreshold=10000
Number of method invocations/branches before compiling [-client: 1,500]
-XX:LargePageSizeInBytes=4m
Sets the large page size used for the Java heap. (Introduced in 1.4.0 update 1.) [amd64: 2m.]
-XX:MaxHeapFreeRatio=70
Maximum percentage of heap free after GC to avoid shrinking.
-XX:MaxNewSize=size
Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.]
-XX:MaxPermSize=64m
Size of the Permanent Generation.  [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]
-XX:MinHeapFreeRatio=40
Minimum percentage of heap free after GC to avoid expansion.
-XX:NewRatio=2
Ratio of new/old generation sizes. [Sparc -client: 8; x86 -server: 8; x86 -client: 12.]-client: 4 (1.3) 8 (1.3.1+), x86: 12]
-XX:NewSize=2.125m
Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]
-XX:ReservedCodeCacheSize=32m
Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]
-XX:SurvivorRatio=8
Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32]
-XX:TargetSurvivorRatio=50
Desired percentage of survivor space used after scavenge.
-XX:ThreadStackSize=512
Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:+UseBiasedLocking
Enable biased locking. For more details, see thistuning example. (Introduced in 5.0 update 6.) [5.0: false]
-XX:+UseFastAccessorMethods
Use optimized versions of Get<Primitive>Field.
-XX:-UseISM
Use Intimate Shared Memory. [Not accepted for non-Solaris platforms.] For details, see Intimate Shared Memory.
-XX:+UseLargePages
Use large page memory. (Introduced in 5.0 update 5.) For details, see Java Support for Large Memory Pages.
-XX:+UseMPSS
Use Multiple Page Size Support w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0 update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]
-XX:+StringCache
Enables caching of commonly allocated strings.
-XX:AllocatePrefetchLines=1
Number of cache lines to load after the last object allocation using prefetch instructions generated in JIT compiled code. Default values are 1 if the last allocated object was an instance and 3 if it was an array.
-XX:AllocatePrefetchStyle=1
Generated code style for prefetch instructions. 
0 - no prefetch instructions are generate*d*,
 
1 - execute prefetch instructions after each allocation,
 
2 - use TLAB allocation watermark pointer to gate when prefetch instructions are executed.


Debugging Options

Option and Default Value
Description
-XX:-CITime
Prints time spent in JIT Compiler. (Introduced in 1.4.0.)
-XX:ErrorFile=./hs_err_pid<pid>.log
If an error occurs, save the error data to this file. (Introduced in 6.)
-XX:-ExtendedDTraceProbes
Enable performance-impacting dtrace probes. (Introduced in 6. Relevant to Solaris only.)
-XX:HeapDumpPath=./java_pid<pid>.hprof
Path to directory or filename for heap dump.Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)
-XX:-HeapDumpOnOutOfMemoryError
Dump heap to file when java.lang.OutOfMemoryError is thrown. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)
-XX:OnError="<cmd args>;<cmd args>"
Run user-defined commands on fatal error. (Introduced in 1.4.2 update 9.)
-XX:OnOutOfMemoryError="<cmd args>; 
<cmd args>"
Run user-defined commands when an OutOfMemoryError is first thrown. (Introduced in 1.4.2 update 12, 6)
-XX:-PrintClassHistogram
Print a histogram of class instances on Ctrl-Break.Manageable. (Introduced in 1.4.2.) The jmap -histocommand provides equivalent functionality.
-XX:-PrintConcurrentLocks
Print java.util.concurrent locks in Ctrl-Break thread dump. Manageable. (Introduced in 6.) The jstack -lcommand provides equivalent functionality.
-XX:-PrintCommandLineFlags
Print flags that appeared on the command line. (Introduced in 5.0.)
-XX:-PrintCompilation
Print message when a method is compiled.
-XX:-PrintGC
Print messages at garbage collection. Manageable.
-XX:-PrintGCDetails
Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps
Print timestamps at garbage collection. Manageable(Introduced in 1.4.0.)
-XX:-PrintTenuringDistribution
Print tenuring age information.
-XX:-TraceClassLoading
Trace loading of classes.
-XX:-TraceClassLoadingPreorder
Trace all classes loaded in order referenced (not loaded). (Introduced in 1.4.2.)
-XX:-TraceClassResolution
Trace constant pool resolutions. (Introduced in 1.4.2.)
-XX:-TraceClassUnloading
Trace unloading of classes.
-XX:-TraceLoaderConstraints
Trace recording of loader constraints. (Introduced in 6.)
-XX:+PerfSaveDataToFile
Saves jvmstat binary data on exit.