Performace Tunning with OSB – RouterRuntimeCache and Proxy initialisation

As your project grows and the number of proxy services you have in the project grows significantly (>100) you might notice that the performance of the services degrades heavily.

This can be attributed to the fact that the OSB is now unable to Cache all your services at runtime.

OSB caches proxy service runtime meta-data using a two-level cache with static and dynamic sections. The cache introduces a performance trade off between memory consumption and compilation cost. Note that caching proxy services may help throughput but could impact memory usage.

The static section is an upper-bound Least Recently Used (LRU) cache that is never garbage collected. When a proxy service is bumped from the static section, it is demoted to the dynamic section where the cache can be garbage collected when there is memory pressure.

Fortunately for us there is a fix for this in place already.

The number of proxy services in the static portion of the cache can be tuned by configuring the RouterRuntimeCache appropriately.

It’s done using a system property com.bea.wli.sb.pipeline.RouterRuntimeCache.size. The default value is 100. Note that this is the number of proxies and NOT dependent on the size of each or proxies so the memory it takes can depend on complexity of these proxies and any Xqueries they call.

This setting can be increased to a desired value provided there is sufficient memory for runtime data processing for large number of proxy services, or you will have to increase the system JVM settings accordingly along with the increase to the runtime cache value.

This property value can be set in the setDomainEnv.sh file as an extra java argument as follows:

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}

Example:

EXTRA_JAVA_PROPERTIES=”-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000 ${EXTRA_JAVA_PROPERTIES}”
Additionally, you might still notice that the first invocation is slow as we see while trying to test the services, this is due to the fact that these services are being compiled then and any future invocations will be a lot faster due to them being in the static Cache.
There is a very interesting article by Mark Smith illustrating how we can utilise this setting to improve the SLA and ensure that the first invocation does not cause you to fail on your SLA. https://blogs.oracle.com/MarkSmith/entry/osb_proxy_initialization/

Ref: http://docs.oracle.com/cd/E25054_01/core.1111/e10108/osb.htm

Weblogic transaction timed out after 302/603 seconds issue

Problem: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 603 seconds

A lot of you might have encountered an issue of Weblogic transaction timed out after 302/603 etc seconds. We have been struggling with this for some time as well.

Non Recoverable System Fault :

Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 603 seconds BEA1-3FB6FB464035C13E3227 at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1748) at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1591) at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1911) at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1501) at weblogic.transaction.internal.WLSTimer.timerExpired(WLSTimer.java:35) at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207) at weblogic.work.ExecuteThread.run(ExecuteThread.java:176) ; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 603 seconds BEA1-3FB6FB464035C13E3227

Solution: Fortunately enough we have managed to find a resolution to this one, which I would like to share.

This issue occurs due to the server time out settings. There are a few settings which you need to update in order to get this resolved.

1. SyncMaxWaitTime (from em console – no Restart required)

2. BPEL EJB’s (weblogic console – requires WLS restart)

3. Global Transaction time out or JTA settings. (weblogic console)

For details on how to change these settings there are a couple of existing articles which one could refer to:

http://orasoa.blogspot.com/2010/04/soa-11g-timeout-settings.html

http://sudhakarsoa.blogspot.com/2011/03/how-do-you-configure-transaction.html

 

 

 

introduction to Oracle Application Integration Architecture

AIA defines a common vocabulary of common business entities and their corresponding services.

AIA defines a common vocabulary across applications and industries. Enterprise Business Objects (EBOs) are the key elements in this context. They canonically describe standard business entities such as an order or an invoice. Based on these generic business entities, AIA delivers other artifacts such as Enterprise Business Services (EBSs), Enterprise Business Messages (EBMs), Enterprise Business Flows (EBFs), Composite Business Processes (CBPs), and Application Business Connector Services (ABCSs). We will describe the purposes of these artifacts and their relationships to each other later when we explain the AIA reference architecture. The combination of all of these SOA artifacts makes up the adaptable and extensible service-oriented reference architecture that AIA stands for.