Thursday, October 02, 2014

SOA Suite 12c - WSM-02141 : Unable to connect to the policy access service

Today, I bumped into a problem with accessing the WSM Policy Manager after I changed the listen address of the SOA managed server in my development environment. The administration server was not able to contact the WSM Policy Manager after the change, causing the problem that I could not run any SOA service test from the EM console
oracle.wsm.policymanager.PolicyManagerException: WSM-02141 : Unable to connect to the policy access service.
After some investigation I discovered that, by default, the WSM Policy Manager is auto-wired in the domain agents and its default targeted to the managed servers and not to the AdminServer. This means that AdminServer uses an agent to connect to the policy manager.

Source: http://docs.oracle.com/middleware/1213/owsm/security/install-owsm-wls.htm#CHDJFHDF
OWSM uses cross-component wiring to auto-discover the Policy Manager in the domain. When you use the Configuration Wizard to create or update a domain that includes OWSM, Policy Manager URLs are published to the Local Service table. The OWSM Agent is automatically wired to the OWSM Policy Manager using the endpoint entries published to the Local Service table.
but that the WSM agent policy manager connection strings were not updated automatically in my environment after I changed the SOA managed server listen address in the WLS admin console. However, this should happen per documentation:

Source: http://docs.oracle.com/middleware/1213/owsm/security/install-owsm-wls.htm#CHDJFHDF
If, however, you change the domain using tools other than the Configuration Wizard (such as the WebLogic Administration Console, Fusion Middleware Control, or WLST), any changes to the Policy Manager URL are automatically published to the Local Service table but the OWSM Agent client is not automatically bound to the new URL. In this case, you need to manually bind the OWSM Agent to the Policy Manager URL. For more information, see "Verifying Agent Bindings Using Fusion Middleware Control".
 The OWSM agents in my environment were still using the old OWSM policy manager url for some reason. To fix my issue I had to go to:
  1. EM console to Weblogic Domain home page -> drop down menu panel -> Cross Component Wiring -> Components. 
  2. Select OWSM agents to go to the OWSM agent component configuration guide
  3. And re-bind the both t3 and http connections strings:


After rebinding both endpoints, the agent client configurations were wired again and the AdminServer was able to connect to the PM and I was able to run a SOA service test from the EM console :)

Please note that also when I target the ws-pm application to the AdminServer I still had to re-bind the agents to update the WSM Policy Manager url.

At least on my environment it looks like a manual rebind is needed in order to update the WSM Policy Manager url in the OWSM agents after a Listen Address of a server hosting the WSM Policy Manager has been changed.

Thursday, July 03, 2014

Oracle SOA Suite 12c tips - Tuning the SOA infrastructure thread pool

One of the new capabilities of Oracle SOA Suite 12c is the ability to control the SOA infrastructure thread pools, except the resource pools for EDN and the adapters, with Oracle WebLogic Server work managers. Each partition will has its own work managers defined. This allows you to separate services in partitions and, to some extent, tune them separately based on for example specific SLA requirements.

Well, this blog posting is not about explaining the SOA 12c thread pool concepts and all the knobs that you can use to tune the thread pools in SOA. That is extensively explained in the Oracle Documentation, so I am not going to repeat that here. What I want to highlight in this blog posting though, is how the SOADataSource impacts the SOA thread pool settings.

In SOA 12c the size of the SOA thread pools is directly controlled by the Maximum Capacity setting of the SOADatasource. If you change the default value of 50 to, lets say, 250, that will also change the Maximum Threads Constraint settings that should be bound by the number of SOA database connections. For example, if the SOADataSource is configured with a maximum of 250 connections this means that the SOAInternalProcessing_maxThreads constraint will be bound to 125. This corresponds to the the SOAMaxThreadConfig internalProcessingPercentage setting that is set to 50% by default.

SOADataSource

SOAInternalProcessing_maxThreads Threads Constraint
SOAMaxThreadsConfig attribute


Having a direct dependency between the SOADataSource connection pool size and the SOA thread pools depending on availability of database connections to the SOA dehydration store, mitigates the risk that SOA runs out of db connections. It is therefore recommended, in most customer scenarios, to only tune the percentages in the SOAMaxThreadConfig configuration attribute or increasing the SOADataSource connection pool. Only dive into the workmanager configurations, such as the Fair Share classes and the thread constraints, if it is really needed.





Wednesday, June 04, 2014

Oracle Traffic Director: Instances, Processes & High Availability explained

Recently, I created a small slide deck to explain how Oracle Traffic Director instances, processes and high-availability concepts work together to front end requests to back end application servers with high availability.

The Oracle Traffic Director (OTD) environment the slide is based on runs on Exalogic Virtual and consists of 3 vServers:
  • 1 for the OTD admin server
  • 2 for the OTD admin nodes
More information about Oracle Traffic Director can be found here: Oracle Traffic Director documentation