Wednesday Jan 30, 2013

OSB Performance Tuning - RouterRuntimeCache

Many customers start out with smaller projects for an initial release.  Typically, these applications require 20-30 Proxy services.  But as time goes on and later phases of the project rollout, the number of proxy services can increase drastically.  The RouterRuntimeCache is a cache implemented by OSB to improve performance by eliminating or reducing the amount of time spent on compiling the proxy pipeline. 

By default, OSB will not compile a pipeline until a request message for a given service is received.  Once it has been compiled, the pipeline is cached in memory for re-use.  You have probably noticed in testing that the first request to a service takes longer to respond than subsequent requests, and this is a big part of the reason.  Since free heap space is often at a premium, this cache can not be infinite in size so this cache has a built in limit.  When the cache is full, the least recently used entry is released and the pipeline that is currently being requested is placed into cache in its place.  The next time a request comes in for the service who's pipeline was released, that pipeline has to be re-compiled and placed in cache, again forcing out the least recently used pipeline.  Once a pipeline is placed in cache it is never removed from cache unless forced out by a full cache scenario as above, or if the service is updated, forcing it to be recompiled.

The default size limit of the RouterRuntimeCache is 100 entries (or pipelines).  It is limited by the number of services in the cache, not the memory used by the cache so the amount of memory used by a full cache will vary greatly based on the complexity of the services, the extent and complexity of inline xquery, etc.  If your project grows beyond 100 proxy services, system performance can degrade significantly if the cache size is not increased to hold all frequently used services. 

Unfortunately, the way to tune this cache is not exposed through the OSB console.  As of 11g PS5, the only way to set this parameter is via a system property specified on the Java command-line.  The property name is com.bea.wli.sb.pipeline.RouterRuntimeCache.size.   For example,

“java … -Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=500 … weblogic.Server …”. 

In this example, OSB will cache 500 proxies, instead of the default 100.  Because increasing the RouterRuntimeCache.size value will require more space in the heap to hold the additional proxies, be aware that you may need to reevaluate your JVM memory settings to allow OSB to continue to perform optimally.

Tuesday Jan 29, 2013

SOA Suite for Healthcare Integration startup errors due to expired passwords.

Background

SOA Suite for Healthcare integration involves starting up the managed servers, which are in turn, dependent on valid connections to databases. In many low-maintenance environment like Virtualbox images distributed for training and workshops, the database passwords are likely to expire after a certain period. Subsequently, the related SOA startup error becomes a road-block for users not familiar with the database dependencies.

This note describes the step-by-step instructions to resolve the password expiry errors and get the SOA Suite for Healthcare Integration environment back up and running.

Symptoms

The errors seen on startup of SOA server could look like the following:

  • Caused by: javax.ejb.CreateException: SDP-25700: An unexpected exception was caught.
  • Cause: weblogic.common.resourcepool.ResourceDeadException:
  • weblogic.common.ResourceException: Could not create pool connection.
  • The DBMS driver exception was: ORA-28001: the password has expired

Remedy

The error is caused by the fact that the database passwords in the image are set to expire after a definite period. To get past the issue, the passwords for the following database users have to be reset:

  • DEV_SOAINFRA
  • DEV_MDS
  • DEV_ORASDPM

These users with DEV_ prefix are the default but could vary in other situations, where custom prefixes may have been used during installation of SOA Suite repository. 

All the passwords can be set to the original value, e.g. welcome1 by logging into a SQL*PLus session as a DBA and using the following command for each database user one at a time :

  • SQL> Alter user <username from above list> identified by welcome1;
The above procedure is applicable to all database users. Alternatively, upon attempts to login to a SQL*Plus session as a database user with expired password, the session itself can prompt for new passwords.

Results

Below, we have the excerpt from a terminal session captured from the Virtualbox image, distributed for SOA Suite for Healthcare Integration training. It shows how the passwords were reset using the approaches mentioned earlier.


[oracle@soahc ~]$ . oraenv
ORACLE_SID = [orcl] ?
The Oracle base for ORACLE_HOME=/u01/DBInstall/product/11.2.0/dbhome_1 is /u01/DBInstall
[oracle@soahc ~]$ sqlplus

SQL*Plus: Release 11.2.0.1.0 Production on Date...

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Enter user-name: system
Enter password: welcome1
ERROR:
ORA-28001: the password has expired


Changing password for system
New password: welcome1
Retype new password: welcome1
Password changed

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter user DEV_SOAINFRA identified by welcome1;

User altered.

SQL> alter user DEV_MDS identified by welcome1;

User altered.

SQL> alter user DEV_ORASDPM identified by welcome1;

User altered.

SQL> conn / as sysdba
Connected.

SQL>


Wednesday Jan 16, 2013

Oracle SOA for Healthcare - Setting Endpoint Acknowledgement Acceptance

Acknowledgment acceptance in SOA Suite for Healthcare is globally set through the console at the document level. Currently there is no way to override the global setting for an endpoint in the SOA for Healthcare console. The illustration below shows acknowledgment acceptance being set in the document type definition in the SOA for Healthcare console

[Read More]
About


This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.

Search

Archives
« January 2013 »
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
31
  
       
Today