Category: WebLogic

Weblogic Server 12c Installation, Weblogic Clustering, Weblogic Work Manager, Data Source Connections, JMS Connection Factory, Weblogic Authentication & Authorization, Weblogic WLST Scripts

pack and unpack domain files in distributed WebLogic domain

The blog discuss about the technical approach on distributing domain files among distributed WebLogic domain infrastructure , means where multiple machines are installed with same WebLogic version installation but have to share the same domain to be used in distributed infrastructure. 

Lets consider we have 2 machine mach1 and mach2 installed with WebLogic Server. 

Machine1 (mach01) :

  • Weblogic Server Installed
  • Managed Servers (mach_ms1, mach_ms2)
  • Domain: dev_soadomain

Machine2 (mach02) :

  • Weblogic Server Installed
  • Managed Servers (mach_ms3, mach_ms4)

Now , our requirement is to have machine2 to be part of the same domain dev_soadomain created in machine1 to be part of the clustered WebLogic domain

Distribute domain files to another WebLogic Server using pack and unpack

  • Log into Machine1 Weblogic Server Admin User
  • Navigate to WebLogic domain folder
[wls@mach01]$ cd $WL_HOME/common/bin
  • Run the below given command to pack the WebLogic domain file from machine1 (mach01)
[wls@mach01]$ ./pack.sh -domain=$DOMAIN_HOME-template=$WL_HOME/
common/templates/domains/DEV_SOADOMAIN_template.jar -template_
name=DEV_SOADOMAIN –managed=true
  • A file is created at $WL_HOME/common/templates/domains/DEV_SOADOMAIN_template.jar
  • Log into Machine2 Weblogic Server Admin User
  • Naviage to weblogic domain folder
  • Copy the DEV_SOADOMAIN_template.jar from machine1(mach01) to machine2(mach02)
[wls@mach02]$ scp wls@mach01:$WL_HOME/common/templates/domains/
DEV_SOADOMAIN_template.jar $WL_HOME/common/templates/domains/
  • Unpack the DEV_SOADOMAIN_template.jar in machine2(mach02) domain folder
[wls@mach02]$ cd $WL_HOME/common/bin
[wls@mach02]$ ./unpack.sh -template=$WL_HOME/common/templates/
domains/DEV_SOADOMAIN_template.jar –domain=$DOMAIN_HOME
  • An entry to the DEV_SOADOMAIN domain will automatically be added to the nodemanager.properties file

Distribute domain files to another WebLogic Server manually

  • Domain Directory in machine1
DOMAIN_HOME = oracle/Middleware/user_projects/domains/DEV_SOADOMAIN
  • Log into Machine2 Weblogic Server Admin User
  • Create the Domain Directory with the same name as in machine1
[wls@mach02]$ mkdir –p $DOMAIN_HOME

Copy the Domain files from machine1 to machine2

[wls@mach02]$ scp –rp wls@mach01:$DOMAIN_HOME $DOMAIN_HOME/..

Edit the e nodemanager.domains in machine1 and make the entry 

[wls@mach01]$ vi $WL_HOME/common/nodemanager/nodemanager.domains
DEV_SOADOMAIN=/oracle/Middleware/user_projects/domains/DEV_SOADOMAIN/

weblogic domain error Malformed argument has embedded quote

The below error encountered when try to create the integrated weblogic domain in Jdeveloper 12.2.1.4.0 ” Malformed argument has embedded quote”  , “java.io.IOException: Cannot run program “cmd.exe”

"C:\oraclesoabpm\oracle_common\common\bin\wlst.cmd" "C:\Users\user\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py""
Cannot run program "cmd.exe" (in directory "C:\oraclesoabpm\oracle_common\common\bin"): Malformed argument has embedded quote: "C:\oraclesoabpm\oracle_common\common\bin\wlst.cmd" "C:\Users\user\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
java.io.IOException: Cannot run program "cmd.exe" (in directory "C:\oraclesoabpm\oracle_common\common\bin"): Malformed argument has embedded quote: "C:\oraclesoabpm\oracle_common\common\bin\wlst.cmd" "C:\Users\user\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at oracle.jdevimpl.adrs.weblogic.wlst.ScriptRunnerImpl.runScript(ScriptRunnerImpl.java:106)
at oracle.jdevimpl.adrs.weblogic.builder.DomainScriptRunnerImpl.runScript(DomainScriptRunnerImpl.java:146)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder.createDomain(DefaultDomainBuilder.java:606)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder.build(DefaultDomainBuilder.java:274)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder$1.run(DefaultDomainBuilder.java:225)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)

The below steps can be performed to resolve the Malformed argument issue.

  1. Navigate to the Jdeveloper 
<MW_HOME>\jdeveloper\ide\bin

2. Open the ide.conf file in the text editor . Enter the below given VM Argument details in the  OSGi configuration options

AddVMOption -Djdk.lang.Process.allowAmbiguousCommands=true

# Other OSGi configuration options for locating bundles and boot delegation.
#
AddVMOption  -Dorg.eclipse.equinox.simpleconfigurator.configUrl=file:bundles.info
AddVMOption  -Dosgi.bundles.defaultStartLevel=1
AddVMOption  -Dosgi.configuration.cascaded=false
AddVMOption  -Dosgi.noShutdown=true
AddVMOption  -Dorg.osgi.framework.bootdelegation=*
AddVMOption  -Dosgi.parentClassloader=app
AddVMOption  -Dosgi.locking=none
AddVMOption  -Dosgi.contextClassLoaderParent=app
AddVMOption  -Djdk.lang.Process.allowAmbiguousCommands=true

3. Restart the JDeveloper . Run the Integrated weblogic domain again.

[Waiting for the domain to finish building...]
[10:29:28 AM] IntegratedWebLogicServer Domain is invalid.  Regenerating it...
[10:29:30 AM] Creating IntegratedWebLogicServer Domain...
[10:32:19 AM] Extending IntegratedWebLogicServer Domain...

ADRS_DOMAIN_PASSWORD error during Integrated Weblogic Domain creation

When tried to create the Integrated Weblogic Domain in JDeveloper , the below error encountered . This error occurs as Weblogic Jython libraries do not recognize the operating system. 

Error:  ADRS_DOMAIN_PASSWORD environment variable not set

The below given steps can be performed to resolve the error.

Option 1: 

Apply the Patch 22138883 as per the JDeveloper Version in your machine.

Option 2: 

Manual update the  jython-modules.jar 

  1. Copy the jython-modules.jar from the Oracle Fusion Middleware home path 
<MW_HOME>\wlserver\common\wlst\modules*

2. Unzip the  jython-modules.jar

3. Open the javashell.py file in the text editor 

4. Search for the variable _osTypeMap

_osTypeMap = (
  ( "nt", ( 'nt', 'Windows NT', 'Windows NT 4.0', 'WindowsNT',
  'Windows 2000', 'Windows 2003', 'Windows XP', 'Windows CE',
  'Windows Vista', 'Windows Server 2008', 'Windows 7', 'Windows 8',
  'Windows Server 2012')),
  ( "dos", ( 'dos', 'Windows 95', 'Windows 98', 'Windows ME' )),
  ( "mac", ( 'mac', 'MacOS', 'Darwin' )),
  ( "None", ( 'None', )),
  )

5. Update by adding “Windows 10” in the “nt”  values of _osTypeMap

 _osTypeMap = (
  ( "nt", ( 'nt', 'Windows NT', 'Windows NT 4.0', 'WindowsNT',
  'Windows 2000', 'Windows 2003', 'Windows XP', 'Windows CE',
  'Windows Vista', 'Windows Server 2008', 'Windows 7', 'Windows 8',
  'Windows Server 2012','Windows 10')),
  ( "dos", ( 'dos', 'Windows 95', 'Windows 98', 'Windows ME' )),
  ( "mac", ( 'mac', 'MacOS', 'Darwin' )),
  ( "None", ( 'None', )),
  )

6. Execute the below command to create the updated jython-modules.jar

jar –cvf jython-modules.jar

7. Place the new jython-modules.jar to the below middleware location

<MW_HOME>\wlserver\common\wlst\modules*

8. Now open the JDeveloper and try to create the integrated weblogic domain process. 


Java VM Initialization error: could not reserve Space For Object Heap

The blog discusses the Java VM Initialization error while running the Weblogic Server. 

Error occurred during initialization of VM
Could not reserve enough space for object heap

The error is an JVM error and encountered when the Java Process cannot create the Virtual machine at run time due to limitations on the Heap Size for memory allocations.  Heap Size is the memory allocation for storing java object at run time. The Heap Size values can be managed though Xmx and Xms VM arguments. 

The below could be the reason for object heap error

  1. The  heap size is not defined to be allocated for the memory
  2. Installed 32 bit JVM in 64 bit machine
  3. The provided heap size -Xmx value is defined too high than to be allocated as per 32- bit VM.
  4. The provided heap size -Xmx value is defined too less than to be allocated as per 32- bit VM.
  5. The provided heap size -Xmx value more than the available physical memory. 

The heap size values will differ based on below configurations

  1. Operating system 32-bit machine or 64-bit machine.
  2. JVM 32/64 bit version
  3. hardware architecture

Identify the Current Heap Size 

In case of Weblogic Server, the server start provides the Java Memory arguments for heap size 

Java VM Initialization error

Modify the Java Heap Size memory arguments

Update the Java memory arguments by performing the below action

Linux: 

 -bash-3.2$ export _JAVA_MEMORY_OPTIONS =”-Xmx512M”

Windows: 

Update the Windows Environment Variables

Increase Java Heap Size

Updating Heap Size for Weblogic Server running SOA

In case the above error is coming while running weblogic server or the managed server like soa_server1 , then you can update the Heap Size Memory allocation in the Environment variable using USER_MEM_ARGS which overrides the value for MEM_ARGS in the setDomainEnv.cmd file of the weblogic domain.

weblogic User Memory arguments

Updating Heap Size from Weblogic Server Console

Perform the below given steps:

  1. Log into the weblogic server console
  2. Click on Servers
  3. Select the Server for which changes need to be done.  (AdminServer) 
  4. Click on Monitoring -> Performance Tab
  5.  Update the Heap Size values.

Weblogic console heap size allocation

Restart the Weblogic Server and memory issue should be resolved now.


Oracle Weblogic : Tuning options for Database Source connections

Web Logic Server provides the capability of connecting to databases using Data Sources. Through Data Sources Web Logic provides the data access and database connection management activities. The created Data Source in Web Logic Server contains the connection pool of database connections for providing connections at run time to perform database operations.

The database operation could be considered costly in terms of performance if not tuned properly. Let’s identify the options what could be applied in different scenarios to achieve high performance while using data source connection pool.

1) JNDI Lookup Calls: Each Database call includes JNDI lookups which could be costly if same statement requires to be executed multiple times. Thus it is important for caching an object that required a look up in client
2) Reuse available connection: It could be useful if the application can reuse the received connection from the pool instead of closing and waiting to reacquire new connection.
3) Timely Connection Release: Connection should be released once it has performed the required action and should not be kept holding.
4) Configuring Row Pre Fetch: Row prefetching improves performance when receiving more rows from the external server to the client server in a single server access. Increasing Row Pre Fetch value will increase performance, until a particular value is reached
It is also to be noted that it is applicable only for external clients, not for clients in the same Java Virtual Machine (JVM) as the WebLogic Server.
Minimum value: 2
Maximum value: 65536
It is advisable to keep Minimum value as 100 as after 100 rows the performance hardly increases.
5) Connection Testing: Web Logic Server provides the way to validate and test the database connection before allocating it to the objects / applications.
The parameter Test Connection On Reserve enables the web logic server instance to check the database connection prior to returning the connection to a client.
The parameter Test Frequency is also used to validate the database connection.
Both these parameters are fairly expensive in terms of performance and should be avoided in the production environment.
6) Prepared and callable Statements: When an application connects to database for fetching the required application data, there are chances to have high processing overhead due to huge data size. Thus Web Logic Server provides the concept of caching the Prepared Statements and Callable Statements so that Web Logic Sever can reuse the statement stored in the cache.

Read the below blog on the detailing about statement cache in Web Logic Server Tune Data source Connection using Statement Cache

7) Limit Waiting Connection Request: If the connection is requested from the Data Source Connection Pool and multiple connection requests are waiting as Connection Pool has reached to its maximum capacity, then it might result into blockage of threads waiting to acquire new connection.
For this reason, the parameter value for Maximum Waiting for Connection (HighestNumWaiters) should be minimum. If the parameter value for Maximum Waiting for Connection is set to 0, then connection requests cannot wait for acquiring a connection and thus SQL exception – PoolLimitSQLException will be returned.

8) Connection Reserve Timeout: When Data Source Connection Pool reaches to its maximum capacity, then PoolLimitSQLException will be returned to the application(s). To avoid receiving the immediate connection timeout exception, configure Connection Reserve Timeout value (in seconds).
Default value for Connection Reserve Timeout: 10 seconds
If Connection Reserve Timeout is set to -1, then it will timeout immediately if no new connections available
If Connection Reserve Timeout is set to 0, then connection request(s) will wait for indefinite timeout till they are allocated with new available connection

9) Shrink Frequency: To increase the availability of connections in the pool Web Logic Server periodically shrinks the connection to its initial capacity based on usage. The Parameter Shrink Frequency value is to let web logic server know the number of seconds to wait before shrinking a connection pool. To Disable the Shrink Frequency, set the value to 0.

10) Database Listener Timeout: In case of applications having huge loads and consuming High CPU Utilization, it is observed that database listener get timeout while creating a new connection and throws ResourceDeadException and Socket read timed out connection errors.
To overcome such issues, it is advisable to increase the timeout value of the database server
sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=180

11) Recovering Leaked Connections: The connections which are not properly returned back to the Data Source Connection Pool can be considered as Leaked Connections. The parameter Inactive Connection Timeout can be configured (in seconds) whenever data source maintenance thread runs it will check for the connections which are Inactive more than the set value in the parameter and will returned them back forcibly to the connection pool.
12) Pinned-To-Thread: Normally the connection request is allocated with the new data source connections and once the thread is executed the connection is returned back. In case of enablement of the PinnedToThread Property WebLogic Server pins a database connection from the data source to a connection requested thread for the first time when an application uses the thread to reserve a connection. After finishing the assigned task, instead of returning the connection back to the connection pool, Web Logic server keeps the connection requested thread and does not return it to the data source and keep it reserved for the next connection requested thread to allocate when request for new connection again.
With the enablement of PinnedToThread property, the connection pooling behaviour will notice the below changes
• Maximum Capacity is ignored
• Shrinking does not apply to connection pools with PinnedToThread enabled as connections are reserved and not returned back to the connection pool
• When web logic reset the connection pool, it marks the connections as Test Needed and for that Test Connections on Reserve need to be enabled as PinnedToThread keeps the connections on reserve.
• The PinnedToThread feature does not work with an IdentityPool, an error is thrown and the data source will not deploy
• With PinnedToThread enabled, does not support connection labelling, exception is thrown when trying to get a connection with label properties
• When PinnedToThread is enabled, the maximum capacity of the connection pool becomes the number of execute threads used to request a connection multiplied by the number of concurrent connections each thread reserves and exceeds the maximum capacity


How to Tune Data Source Connection Pool using statement cache

The Data Source connections are required to retrieve / store the application data from/to the database. The Web logic Server provides the below types of statements to be executed to exchange the data from database.

1. Statements (General SQL Statements)
2. Prepared Statements
3. Callable Statements (Stored Procedure)

When an application connects to database for fetching the required application data, there are chances to have high processing overhead due to huge data size. Thus Web Logic Server provides the concept of caching the Prepared Statements and Callable Statements so that Web Logic Sever can reuse the statement stored in the cache.

The Statement Cache is applicable on the Data Source, however each connection maintains its own statement cache for Prepared Statements and Callable Statements

Possible configurations for Statement Cache:
1. Statement Cache Type:
The statement cache type uses the below given algorithm to identify which statements to be stored in the statement cache.
LRU Algorithm: LRU is Least Recently Used algorithm defined as default for the statement cache type.
When a Prepared Statement or Callable Statement is received by the Web Logic Server for processing, it validates from the Cache statements with the statements already in cache.
– If the received statement exists, then Web Logic Server returns the statement and execute the existing statement for processing.
– If the received statement does not exist and considered to be as new statement, then Web Logic Server validates statement Cache Size or confirm if total cache size is reached or not.
o If the cache size is not reached, then Web Logic Server will store the statement
o If the cache size is reached, then Web Logic server will check for the statement which is least recently used and replace the least recently used statement with the new statement.

Fixed Algorithm:
In case of Fixed algorithm, Web Logic Server accepts and store the statements in cache till the statement Cache Size is reached. Once the statement Cache Size is reached, the newly received statements will not be cached.

2. Statement Cache Size:
The statement cache size is the total number of Prepared Statement or Callable Statement which are allowed to be cached for each connection of the data source in the Web Logic Server.
It is to be noted that too many open connections might impact the DBMS resource cost if cursors are included for execution.

The memory consumption depends on the below calculations
number of data sources * number of connections * number of statements
Example: Let’s assume the below numbers
Data Source connection: 10
Deployed Servers: 2
Statement Cache Size: 10
As per the calculation the total open cursors required at database server will be (10 *2*10) = 200 cursors for the cache statements.

Setting the size of the statement cache to 0 turns off statement caching
Minimum value: 0
Maximum value: 1024


change the default load balancing algorithm in Weblogic Server

The Weblogic Server provides additional capability for managing the Clustered Environments using the load balancers with available load balancing algorithms.

The Weblogic Server Load Balancing Algorithms

  • Round Robin Load Balancing: Round Robin Load Balancing is the default load balancing strategy for clustered objects supported for RMI objects and EJBs
  • Weight -Based Load Balancing:  The Weight -Based Load Balancing in Weblogic Server assign each server with pre-defined weight.  Select Server -> Configuration -> Cluster tab in the Administration Console  and assign each server in the cluster with a numerical weight between 1 and 100.
  • Random Load Balancing:  The Random Load Balancing algorithm in Weblogic Server routes the requests randomly to the server. This algorithm is suitable for homogeneous cluster deployments where each server runs with the similar configurations.  The random method of load balancing applies only to EJB and RMI object clustering.
  • Server Affinity Load Balancing: The Server Affinity Load Balancing algorithm in Weblogic Server turns off load balancing for external client connections and prefers to use the existing Weblogic Server instance. If an object is configured for server affinity, the client-side stub attempts to choose a server instance to which it is already connected, and continues to use the same server instance for method calls.  There are 3 types of Server Affinity Load Balancing algorithms. Server affinity is used in combination with one of the standard load balancing methods: round-robin, weight-based, or random:
    • round-robin-affinity—server affinity governs connections between external Java clients and server instances; round robin load balancing is used for connections between server instances.
    • weight-based-affinity—server affinity governs connections between external Java clients and server instances; weight-based load balancing is used for connections between server instances.
    • random-affinity—server affinity governs connections between external Java clients and server instances; random load balancing is used for connections between server instances.

Steps to update the load balancing algorithm

1. Log into the Web Logic Admin Console
2. click Lock & Edit to make changes
3. Select Environments > Clusters
4. Select the Cluster Name from the given table.
5. Select the Load balancing algorithm for the available options.
6. Select Advanced and Enter the value for Service Age Threshold
7. Click Save
8. Click Activate changes.


Difference between Clustered environment and Non-clustered environment

The Weblogic Sever 12c provides the Clustered Infrastructure which is most suitable for production environment with enhanced security features. The blog provides the detailing on how Web Logic Clustered environment is different from Non-clustered environment.

Before that , please find below the blog link on the Web Logic Server Clustering Overview understanding clustering in Weblogic 12c

Clustered Environment vs Non-Clustered Environment in Weblogic 12c

The Clustered Environment is similar to Non-Clustered Environment except from the point that Cluster Web Logic Clustered Environment will provide below given additional features which are quire useful in case of time critical applications which are not supported through non-clustered environment.

  • Weblogic Server 12c Fail over mechanism :

Failure is the process when the web logic server is executing an object which could be the web logic resource, application component / service which needs to be completed as per the received service request but fails due to some reason.
In the Non-clustered environment, this failed object cannot be recovered or cannot instantiate a new object copying the failed object details to resume its processing. The clustered environment provides that support.

The clustered environment maintains the copy of the failed object.
The Web Logic program which manages failover process should be having the Object information which are in process including the location, operational status and overall progress of the in process object.
Web Logic Server also maintains the information regarding the IP Sockets and Java Naming and Directory Interface (JNDI) to share and maintain information about each object running in the Web Logic clustered environment.

Web Logic Server maintains the State of an object (what has been done for the object) using the Session Replication and Replica Aware Stubs techniques.

  • Load Balancing in Weblogic Server:

To avoid huge load on a single server, the Web Logic Clustered environment uses the technique of Load Balancing to ensure fair load on each server instance to increase performance, scalability and reliability of executed services.
Load balancing is the mechanism through which distribution of jobs will be performed using the Load Balancing Algorithm. By default, Web Logic uses Round-Robin Algorithm.

  • Automatic Migration Process in Weblogic Server:

Also Web Logic Clustering provides the Automatic Migration Process which means migration of clustered server instances from one machine to another at the run time to avoid failure of the in progress services / applications.


Understanding Web Logic Server 12c Clustering

The blog provides the overview of Clustering Configuration in he Weblogic Server 12c . Web Logic Server 12c is an Application Server which executes Web Application(WAR) and Enterprise Application (EAR) developed in Java.
The Oracle Fusion Middleware allows the installation of Web Logic Admin Server as well as Managed Servers like SOA Server, OSB Server and ADF Server to provide the complete deployment environment for Oracle Fusion Middleware Applications.

How to improve Weblogic Server 12c performance and Scalability


It has become common to have multiple server to provide performance as well as increased scalability and reliability when large applications with critical components to be executed in the heterogeneous environment. Thus, IT companies are preferring the usage of Web Logic Clustering as the optimized solution for running such applications.

What is Clustering in Weblogic Server 12c ?

Web Logic Clustering is the mechanism in which multiple Web Logic Server Instances are running and thus provides client with the single web logic server instance. Web Logic Cluster could have server instances on the same machine or can connect to multiple machines for increasing clustering capacity. It is important to note that each server instance in the Web Logic Cluster must be running with the same version of Web Logic Server.

To run the Web Logic Server through Admin Server, we need to CREATE the Web Logic DOMAIN. A Web Logic Domain is a combination of Web Logic server resources (Data Sources, Adapters, JMS Queues and Connections, etc.), application components, application services and server instances. Which means that a DOMAIN is a combination of multiple server instances which can be clustered, non-clustered, or a combination of clustered and non-clustered instances.
Each domain consists of Admin Server and other managed servers like SOA Server, OSB Server, ADF Server. The Admin Server configures, manages and monitors all other server instances. Thus, it clarifies that all server instances must resides in the same DOMAIN.

Also read to know how Web Logic Clustered environment is different from Non-clustered environment from the below given link

Clustered Environment vs Non-clustered Environment

Which Objects are considered as part of Web Logic Clustered Environment?

In the Web Logic Clustered Environment , each task executed in terms of Object. An application object could be different type, having different behavior including object invocation process, features and functions within an application when gets consumed. Below given are the main types of objects in the Web Logic Clustered deployment.

• Servlets
• JSPs
• EJBs
• Remote Method Invocation (RMI) objects
• Java Messaging Service (JMS) destinations

Web logic Server provides the support for Servlets and JSPs in the Clustering Environment by replicating the HTTP Session State of the Client that accesses servlets through clustered environment.
The HTTPS Sessions State can be maintained in the memory, a file based system or in the database by the Web Logic Server as per the configuration.
For the Enterprise Java Beans and Remote Method Invocation (RMI) objects, the Web Logic Server uses the Replica-Aware Stubs which can locate the instances of the object within the clustered environment.
In the object fails for EJBs or RMIs then the the stub detects the failure and retries the call on another replica

Which Objects are NOT considered as part of Web Logic Clustered Environment?

File services with File Shares and the Time Related Services will not be considered as part of Load Balancing or Failover techniques but can still be utilized in the Web Logic Clustered Environment as independent services.

The below given blog provides the distribution of domain file in the Distributed Weblogic Infrastructure

Distributing Domain File using Pack and Unpack


WebLogic Performance Tuning & Thread Management

The deployed application on Web Logic Server requires the availability of resources to execute the received service request and provide the corresponding response back to the application users.

All services are executed through Threads in the Web Logic Server. Each request serviced by the available thread from the Thread Pool. Thus, it is important to ensure that the available threads are not consumed completely and resulting into the Thread Deadlock and impacting the Web Logic Server performance.

Management of Threads in Previous Release before Web Logic 9.0
Till the previous Web Logic 9.0 Release, separate execute queues were maintained for different type of work (service request) executed by the Web Logic Server and users were provided with the creation of user defined thread pool. Thus, Web Logic admin had to manage multiple execute queues and multiple thread pools and required more time for diagnosing the exact reason for the consumption of stuck threads.
Management of Threads through Single Thread Pool
Web Logic Server provides Single Thread Pool and Single Execute Queue from Release 9.0 onwards.
How it works then with Single Thread Pool and overcome performance issue? Web Logic Server executes the received request based on priority. All type of work (service request) executed through Single Thread Pool and automatically maintains the Thread Count (increase / decrease of threads) and thus self –tuned itself.

Web Logic Server introduced Work Manager, which acts as the mechanism to prioritize the work and allocate the threads from the Thread Pool based on the rules defined for execution. The Web Logic Admin can use the pre-defined rules provided by the server or can setup the rules considering the run time performance, throughput and monitoring activities.

Below given are the pre-defined Rules /Constraints provided by Web Logic Server:

1) Fair Share Request Class:
2) Response Time Request Class:
3) Min Threads Constraint:
4) Max Threads Constraint:
5) Capacity Constraint
6) Context Request Class

Work Manager Types:
The Work Managers are classified into below given 3 types
1. Default Work Manager: If the application does not specify the Work Manager, then Web Logic Server Default Work Manager will be used to handle the thread management and request processing. It also manages self-tuning to avoid performance issues.
2. Global Work Managers: The global work manager will be available to all the deployed applications in the Web Logic Server. The application uses the work manager as a template. Each application will get its own instance at run time and thus Work Manager can execute respective application requests separately based on application instance.
3. Application Scoped Work Managers: Work Manager can be created in such a way that they perform requests for a specific application or module deployed in the Web Logic Server.

The application scope work managers can be defined in the Web Logic Admin console or can be added through the below given description files in the application
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
What is the ideal situation to use Work Managers?
The Work Manager can be used when the below reasons are valid for the deployed application(s)
1. The default fair share (50) is not sufficient. This happens when multiple applications are deployed and one of the application request have more priority.
2. When it is required to set the response time goal.
3. When minimum thread constraint value need to be provided to avoid server deadlock


Work Manager request classes in WebLogic Server

Web Logic Server introduced Work Manager, which acts as the mechanism to prioritize the work and allocate the threads from the Thread Pool based on the rules defined for execution. The Web Logic Admin can use the pre-defined rules provided by the server or can setup the rules considering the run time performance, throughput and monitoring activities.

Below given are the pre-defined Rules /Constraints provided by Web Logic Server:

1) Fair Share Request Class:
2) Response Time Request Class:
3) Min Threads Constraint:
4) Max Threads Constraint:
5) Capacity Constraint
6) Context Request Class

Fair Share Request Class:
This rule configures the average thread use time required to process the received requests
Uses the relative value and not the percentage value
Minimum value is set to 1 and maximum value could be 1000

Example: Let say 2 Request Classes such as RC1 and RC2 are defined as 120 and 40, then the relative value will be 3:1 Thus the RC1 chance to get executed by the next free thread will be (120/160) = 0.75 %.
Similarly, the RC2 chance to get executed by the next free thread will be (40/160) =0.25 %

Response Time Request Class:
This rule configures the response time goal in milliseconds. The tolerable waiting time is computed by WebLogic Server by calculating the average response time goal for the received requests and schedules the request to ensure the average wait for the request should be less than to the defined tolerable waiting time.
Default value for response time goal is -1 which indicates that response time goal is not defined to be calculated at run time.

Context Request Class:
This rule configures the Request classes to the received service request based on the request context information like current user or current user group.

Example:
<work-manager>
<name>ResponseTime_RCWM</name>
<response-time-request-class>
<name>TestApp_ResponseTime</name>
<goal-ms>1000</goal-ms>
</response-time-request-class>
</work-manager>

<work-manager>
<name>Context_RCWM</name>
<context-request-class>
<name>TestApp_Context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
It is preferable to set session timeout values to avoid session expiration while request wait in the Work Manager queue.

Work Manager defines constraints which sets the limit for the minimum and maximum threads that can be allocated to execute the received service requests. It also calculates the total number of received requests that can be queued (waiting to be executed in the queue) and rejects the received request if exceeds that limit to avoid server health issue.

Min Threads Constraint:
This rule sets the minimum limit of threads required for executing the received requests for processing.
Default value is unlimited.
Max Threads Constraint:
This rule sets the maximum limit of threads required for executing the received requests for processing

Capacity Constraint:
This rule sets the capacity value which when reached allows Web Logic Server to reject the received requests from processing.


No credential mapper entry found for password indirection

The Developers using Weblogic Server for Deployment might get the below given error

weblogic.common.ResourceException: java.security.PrivilegedActionException: weblogic.common.ResourceException: No credential mapper entry found for password indirection.

This sort of error comes when you have multiple data source connections defined and WebLogic Server validates the data source connection and tries to make entry in the jdbc.xml

If we enable the option Auto Generate and synchronize weblogic-jdbc.xml descriptiors using deployment then weblogic server will try to read the file from the EAR getitng deployed and thus genereated the PrivilgedActionException in case of not getting proper values from the EAR file.

No credential mapper entry found

UnCheck the Auto Genrate Option and let the weblogic server to generate this file at run time for your EAR application