Saturday, September 22, 2012

Cluster Constraint for the deployment in weblogic server

Cluster Constraint for the deployment in weblogic server

Cluster constraint specifies that deployments targeted to a weblogic cluster succeed only if all servers in the cluster are running.

When this option is enabled, WebLogic Server enforces a strict two-phase deployment policy for all Managed Servers in a domain—ensuring that application deployment to a cluster succeeds only if all Managed Servers in the cluster are reachable and can deploy the application. If any server instance in the cluster is unreachable, the application is not deployed to any of the Managed Servers.

If you do not enable this option, WebLogic Server allows deployment to a partial cluster. When the unreachable Managed Server becomes available, deployment to that server instance will be initiated.

By default, cluster constraints are disabled and deployment is attempted only on the servers that are reachable at the time of deployment from the Administration Server.

To Enable Cluster Constraint:

  • Login to Weblogic Admin Console
  • Click on the domain name
  • Select the Check box against “Enable Cluster Constraint”




Installing the patches to weblogic server using Oracle Smart Update

Installing the patches to weblogic server using Oracle Smart Update:

Oracle Smart Update tool help us to apply and manage the patches for weblogic server.

As of Smart Update 3.3.0, the Get Patches tab has been removed, and you can no longer use Smart Update to download patches, service packs, maintenance packs, or version upgrades. You must first download the appropriate patch or patches directly from My Oracle Support. Once downloaded, you can use Smart Update to apply the patches.

Smart Update 3.3.0 no longer prompts you to register for security updates from Oracle Configuration Management (OCM).

The version can be verified from Help -> About.

This blog will explain the steps to install the patches to a weblogic server using Oracle Smart Update.

Steps to install the patches to a weblogic server using Oracle Smart Update

  • Download the patch through metalink using the patch id or bug no.
  • Uncompress patch zip file to $MWHOME/utills/bsu/cache_dir (If the cache_dir folder is not available then create the same)


  •  Launch the Oracle Smart Update Tool (bsu.cmd) from $MWHOME\utils\bsu, this will list all the applied patchs and all those patches that are ready for installation.


Friday, September 21, 2012

CodeCache is full. Compiler has been disabled - Oracle SOA Suite 11g

CodeCache is full. Compiler has been disabled - Oracle SOA Suite 11g:

Frequently we used to see the below message in our log file.

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

The code cache is a memory area separate from the JVM heap that is used for compilation and storage of native code.This is where the JIT compiled methods are kept.

The JIT compilier will be disabled when the code cache is full. Once the JIT compiler is switched off due to the Code Cache being full, it does not switch back on.

This will affect the performance of the server in high extend.

We can try to increase the default code cache size to resolve this issue.

Steps to increase the code cache size(we have increased to 64m)

  • Login into Admin Server node
  • Open $DOMAIN_HOME/bin/setSOADomainEnv.sh file 
  • Edit the "DEFAULT_MEM_ARGS" to add the following parameters at the end of line before double quotes: -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m
  • Login into admin console and go to all the servers server start up properties tab and edit the section to add the following parameters at the end of the line  -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m

  • Restart all servers (Admin and Managed)



Monday, September 17, 2012

Import/Publish the services from Oracle Service Bus to Service Registry

Import/Publish the services from Oracle Service Bus to Service Registry:


The OSB services can be published to OSR; the service consumer can consume the services from the OSR also OSB can import and consume the services from OSR.

This blog provides the step to configure and import/publish the services to OSR.

Configure the OSR:

  • Login to OSB console
  • Select System Administration and click on UDDI Registries and click Add Registry
  •  Enter the Oracle Service Registry details as shown below and click on save




Storing the Cross reference data to a custom table - Oracle SOA Suite

Storing the Cross reference data to a custom table - Oracle SOA Suite:


Cross references enable you to dynamically map values for equivalent entities created in different applications. Cross references are stored in the form of tables.

Oracle SOA Suite 11g provides the new feature to store the cross reference data to a custom table instead of storing to a standard XREF_DATA table, this feature enable as to manage the data properly.

Different tables can be created based on the data like order data can be stored in XREF_ORDER table and account data can be stored in the XREF_ACCOUNT. This will improve the performance of populating and looking up the data whenever the volume of the data is more.
  • Right-click the project and select New.
  • Select SOA Tier from the Categories section, and then select Transformations.
  • Select Cross Reference (XREF) from the Items section.

The screen is different in Oracle SOA Suite 12c to create the custom XREF.

oracle_soa_12c_custom_xref



  • Click OK.
  • In the File Name field, specify the name of the cross reference file.
  • In the End System fields, enter the end system names.


  • Click OK.