OAM 11g Webgate Tuning

INTRODUCTION This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. People typically are introduced to Webgate tuning in one of two ways, either forced into it because of a crisis or […]

Valuable Tools For Diagnostics Gathering and Troubleshooting

Introduction The Oracle A-Team is often asked to help customers identify a myriad of JVM and SOA application issues.  Without fail, the customer will be asked for data regarding their application.  This is not application data, but rather data about the running application from the JVM’s perspective. The data we ask for normally includes Java […]

Tuning Considerations for WC Sites

Introduction This quick blog post explores some basic things clients and partners can do to ensure that WC Sites performs well. Main Article Sites engineering has recently provided some insights into common-sense best-practices when it comes to deploying WC Sites on modern hardware. Below is a quick high-level summary of some issues that many clients […]

Which managed server needs Java Object Cache and how to verify JOC is running


My college Yannick already wrote very good article about how to configure Java Object Cache in clustered environment you can find HERE.

There are two things on top of that, I would like to share regarding the Java Object Cache: which managed server needs JOC and the second one is how to verify if JOC is running.

The documentation section here, says that the JOC should be configured on all servers running Oracle Web Service Manager OWSM and Oracle WebCenter Portal’s Spaces application. The tricky part here is where the OWSM runs. The application you have to look after in your WebLogic Administration Console is the “wsm-pm”

iwsp-pm application

If you click on the application and then go to the target tab…

wsp-pm target servers


…you will see there all managed servers targeting this application. Those are the servers for which you have to configure JOC. By default the wsp-pm does not runs on all those servers but only on the utilities, spaces and custom portal. If you want to secure web services from other custom application or existing web services like for example from UCM, you have to target this application to the according managed server which runs the application. After that you would need to extend your JOC configuration to cover this server as well.

Next important step is how to validate that the JOC runs?

First option will be to have a look inside the diagnostic log file from your managed server (<managed_server_name-diagnostig.log>) and search inside for JOC. After you configure JOC you have to restart the managed servers and you should see something like that:

[2013-03-14T14:17:57.685+01:00] [WC_CustomPortal] [NOTIFICATION] [] [oracle.as.cache.Lifecycle] [tid: [STANDBY].ExecuteThread: ‘2’ for queue: ‘weblogic.kernel.Default (self-tuning)’] [ecid: 0000Jpd36SXFw000jzwkno1HGSrd000002,0] [APP: wsm-pm] JOC is initialized from oracle.mds.internal.cache.JOCCacheProvider.createNamedCacheInternal, ver=, distribute=true, vid=1, coordinator=0, discover list=[[localhost:9991] segID=1, SSL]

This message appears only if the wsm-pm application targets the managed server into which log file you look.

Another possibility to verify the JOC is to use CacheWatcher as described HERE. The issue here is that the ORACLE_HOME is not clear to everyone, since there is also modules folder inside the middleware folder. If you as classpath the middleware modules folder, you will get following error message:

Exception in thread “main” java.lang.NoClassDefFoundError: oracle.ias.cache.CacheUtil

In that case, make sure that your classpath goes to oracle_common/modules folder, to get this running:

./java -classpath “/u01/app/oracle/product/Middleware/oracle_common/modules/oracle.javacache_11.1.1/


oracle.ias.cache.CacheUtil watch -config=



If you want to learn more about the JOC how it works or how to monitor it, follow this link HERE


New AIA 11g Performance Tuning Whitepaper available!

The Oracle A-Team has published a new AIA 11g performance tuning whitepaper – see
This summary shows step-by-step how to increase throughput and response time by doing this as an exercise with the AIA 11.2 O2C COMMS PIP.

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. 

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

“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.

Java Tuning in a Nutshell – Part 1

While delivering a training recently, I got
a request to put together a JVM tuning cheat sheet. Given the 50+ parameters available
for the Sun hotspot, this request is understandable. The diagram below is what
I came up with. I’ve tried to narrow down the most important flags that will
solve 80% of JVM performance needs with 20% of the tuning effort. This article
assumes basic JVM tuning knowledge – the different generations used in the Sun hotspot JVM,
different garbage collection algorithms available, etc. Although this is… read more