OSB Proxy Initialization
By MarkSmith on Dec 24, 2010
There currently is a constraint on OSB where the first message that is processed, takes longer than expected. All subsequent messages are processed at the expected super-fast speed. As a result, the first message may break your SLA's.
The reason for this is because the OSB Router Runtime Cache is populated on the first invocation and additionally there is also some "compilations" that take place. (Eg: XQueries) There maybe a future release of OSB that eliminates this issue, but in the mean time, this is one way of solving it by writing a bit of code.
The solution is based on the following scenario:
JMS Proxy ---> calls Proxy A ---> calls Proxy B ---> calls Proxy C ---> calls JMS Business Service
Each proxy does some XML Document validation and executes an XQuery.
The solution to this problem is to pre-initialize each message flow when the Managed Server starts. This initialization process can be triggered by something like WebLogic Application Life Cycle Events.
As the initial JMS Reader Proxies can not be used as live request messages may be waiting on the input queue, the first proxy is bypassed and the rest of the process flow (proxy chain) is initialized by a dummy message. In this case, a HTTP Proxy can be used to send this initial message into the main flow.
The above scenario was initialized by the following:
HTTP Proxy ---> calls Proxy A ---> calls Proxy B ---> calls Proxy C ---> calls Business Service
This is represented by the following diagram:
The timings of the first invocation without initialization is the following:
So rather than using the first "live" message to initialize the message flow as in the original scenario, we use the HTTP proxy to initialize the flow when the server starts and before any "live" messages are processed.
The timings of the HTTP initialize proxy are the following:
From the above timings, we can see that they are similar to the previous image.
Now that the main flow has been initialized, the first message via the JMS Proxy has the following timings:
These timings now fall below the customers SLA and are acceptable. As this is the first time the JMS Proxy has been called, the maximum time is spent in that proxy. Further invocations subsequently reduce that time.