Thursday, 5 May 2011

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



SSL Exceptions in Admin Server and Node Manager


SSL EXCEPTIONS IN ADMIN SERVER AND NODE MANAGER.

javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from oracle.test.com – xx.xxx.xx.xx. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
The above exception is one of the most common exception encountered during the setup of Weblogic Server in an environment. The stack does suggest what could be the reasons but the diagnostics are not mentioned.
To debug this issue -

 First we need to check the certificates used by Admin Server and the Node Manager.

(1) 

 If we have Admin and the Node Manager using demo certificates -

1->Then the issue can be due to improper DNS mapping. We can use the nslookup to check the DNS entry.
2-> For testing purpose we can provide the ip address as the listen address for the admin server and the node
       manager and see if the issue is still occurring.
3-> Also we will have to turn of host name verification and the basic validation check of the certificates. We
      can do it by specifying the following flag in startWeblogic.sh
     -Dssl.debug=true -Dweblogic.security.SSL.ignoreHostnameVerification=true  \
     -Dweblogic.security.SSL.enforceConstraints=off
       And the following flag in startNodeManager.sh
      -Dssl.debug=true -Dweblogic.nodemanager.sslHostNameVerificationEnabled=false \
      -Dweblogic.security.SSL.enforceConstraints=off

(2)
If the Admin Server is using Custom Identity and Custom trust, then its better to configure the node manger with custom identity and custom trust as well.
By default the Node Manager is configured with Demo Identity and Demo Trust. To change it to custom identity and custom trust, we need to specify the following values in the nodemanager.properties file present in nodemanager home
Keystores=CustomIdentityandCustomTrust
CustomIdentityAlias=
CustomIdentityKeyStoreFileName=
CustomIdentityKeyStorePassPhrase = xxxxxx
CustomIdentityKeyStoreType = JKS
CustomIdentityPrivateKeyPassPhrase = xxxxxxx
Apply the same flags as above in the startup script of Admin Server and Node Manger.
Check from the console whether Node Manager is reachable or not.
(3)

Another option can be to use PLAIN communication between Admin Server and Node Manager.
We can change the Listen Type to PLAIN for the Node Manager from the console and set the secureListener=false in the nodemanager.properties file present in nodemanager home.

Oracle Coherence 3.7: Coherence*Web Session Management


Oracle Coherence clustering and Coherence*Web


One common use case for Oracle Coherence clustering is to manage user sessions - conversational state - in the cluster. 


This capability is provided by the Coherence*Web module, which is a built-in feature of Oracle Coherence. 


Coherence*Web provides linear scalability for HTTP Session Management in clusters of hundreds of production servers. 


It can achieve this linear scalability because at its core it is built on Oracle Coherence dynamic partitioning.



What is Coherence*Web?


Coherence*Web is an HTTP session management module dedicated to managing session state in clustered environments. Built on top of Oracle Coherence, Coherence*Web:


•  Enables session sharing and management across different web applications, domains and heterogeneous 
   application servers;
•  Brings Coherence data grid's data scalability, availability, reliability and performance to in-memory session
    management and storage;
•  Supports all the mainstream application servers such as Oracle WebLogic Server, IBM WebSphere,  
   Tomcat, etc.;
•  Supports numerous portal containers including Oracle WebLogic Portal;
•  Allows session state to be managed in the various caching topologies available in Coherence (i.e. 
   Replicated, Partitioned, Near Caching, Read-Through, Write- Through, Write-Behind and Refresh-Ahead  
   Caching, etc.);
•  Allows storage of session data outside of Java EE application server – freeing up application server heap  
   space and enabling server restarts without session data loss;
• Supports multiple advanced session models which define how the session state is physically managed,   
   serialized and deserialized in the cluster;
• Supports fine-grained session and session attribute scoping by way of pluggable policies.


Coherence*Web is not a replacement for WebLogic Server's in-memory HTTP state replication services. However, Coherence*Web should be considered when an application has large Http Session State objects, when running into memory constraints due to storing Http Session object data, and/or have existing Coherence Cluster and would like to offload Http Session storage to a Coherence Cluster.





Coherence*Web is an alternative to WebLogic Server's in-memory HTTP state replication services. Consider using Coherence*Web if you are encountering any of these situations:
  • your application works with large HTTP session state objects
  • you run into memory constraints, due to storing HTTP session object data
  • you want to off-load HTTP session storage to an existing Coherence cluster
  • you want to share session state across EAR files.

Location of the WebLogic Server Coherence*Web SPI in Coherence Distribution



The Weblogic Server Coherence*Web SPI consists of the coherence-web-spi.war file, located in the coherence\lib directory in the Coherence distribution. The coherence.jar file, located in the same directory, is also necessary for enabling Coherence*Web functionality in WebLogic Server.
------------------------------------------------------------------------------------------------------------------------------------------------------------------

Requirements for using Coherence*Web SPI

The Coherence*Web SPI for Weblogic Server requires that a load balancer which enforces http session JVM affinity is running in front of the WebLogic Server tier. WebLogic Server ships with several different proxy plug-ins which will enforce JVM session stickiness.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------

In Coherence*Web, the following default cache configurations are defined:
  • The Coherence*Web SPI for WebLogic Server is configured with local-storage disabled. The server will serve requests and will not be used to host data. This means a Coherence cache server must be running in its own JVM, separate from the JVM running WebLogic Server.
  • The timeout for requests to the cache server to respond is 30 seconds. If a request to the cache server has not responded in 30 seconds, a com.tangosol.net.RequestTimeoutException exception is thrown.
The session-cache-config.xml file contains the Coherence cache configurations used by the Coherence*Web SPI. This file is located in the coherence-web-spi.war file under the WEB-INF\classes directory. 

Enter any cache configuration changes in the session-cache-config.xml file and then repackage it in the coherence-web-spi.war file.

Coherence*Web provides several session locking modes to control concurrent access of sessions. 

Both Coherence*Web and the Coherence*Web SPI employ Optimistic locking by default. This allows concurrent access to a session by multiple threads in a single JVM or multiple JVMs while prohibiting concurrent modification. 

By itself, the Coherence*Web SPI does not require a load balancer to run in front of the WebLogic Server tier. However, you will require a load balancer if you employ sticky session optimization with any of the non-Optimistic locking modes. The default load balancer enforces HTTP session JVM affinity, however, other load balancing alternatives are available. WebLogic Server ships with several different proxy plug-ins which enforce JVM session stickiness.