In 10g, there was a mechanism for suppressing consumption of messages at the Adapter level. That mechanism can not be used in 11g. But there is a way...
The way to do this is to set the InboundThreadCount in the appropriate MBean to zero. This will effectively suppress consumption of messages - e.g. from MQ or JMS or whatever. Setting this value to something greater than zero will cause consumption to resume. Making such a change is dynamic – i.e. no restart required.
This situation is easily handled through Enterprise Manager and can be done in either of two ways.
1. Navigate through the System MBean Browser and make the change there
2. Identify the composite, click through the appropriate item in the Services & References section, select the Properties tab, make the property change and Apply
Either of these techniques are reasonable when there are very few composites to manage.
However, now consider the situation when your installation has many Adapters across many Composites. And, for whatever reason, you need to (effectively) stop or restart the Adapters. In this case, a programmatic approach will be less cumbersome and more efficient.
What we need is a program that uses a control file that defines the Services in the context of the Composite that uses it / them
Here's the definition of the control file:-
<?xml version="1.0"?> <xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="AdapterControl"> <xs:complexType> <xs:sequence> <xs:element name="compositeDetail" minOccurs="1" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="composite" type="xs:string"/> <xs:element name="revision" type="xs:string"/> <xs:element name="partition" type="xs:string"/> <xs:element name="service" type="xs:string"/> <xs:element name="location" type="xs:string"/> <xs:element name="application" type="xs:string" default="soa-infra" minOccurs="0"/> <xs:element name="threads" type="xs:positiveInteger" default="1" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
So that's the schema definition. It's self-explanatory. Now let's look at an actual control file that manages just one Adapter (defined by its Service name) within a specific Composite.
<?xml version="1.0" encoding="UTF-8"?> <AdapterControl xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'> <compositeDetail> <composite>MQResponder</composite> <revision>1.1</revision> <partition>default</partition> <service>MQInbound</service> <location>AdminServer</location> <application>soa-infra</application> <threads>1</threads> </compositeDetail> </AdapterControl>
All of the elements apart from <threads> are needed to identify the MBean that needs to be modified. The MBean object name is complex. Here's an example:-
Actually, that's not a real example. What you see here is an MBean object name with embedded tokens. The application that I'll present here replaces these tokens prior to performing the lookup. Note that the control XML does not contain the "label". This is derived from the other data provided in the control file.
If you review the XSD at this point, you will note that the <compositeDetail> element may repeat. Furthermore, note that the <application> and <threads> elements are optional.
The <threads> element is needed where users run with multiple adapter threads. If you only ever have one thread, then you don't need it. When stopping a service, this element is not used (because we're going to set the InboundThreadCount to zero).
The application usage is as follows:-
StopStart stop|start host port username password control_file
More than likely, you'll run it something like this:-
java -jar AdapterControl.jar start localhost 7001 weblogic welcome1 "c:\users\aknight\my documents\AdapterController.xml"
The program does not validate the XML control file against the XSD at runtime. Bad things will happen if the XML structure is non-conformant. But don't worry too much as it can't damage your runtime system.
Internally, the application is using the Fabric API (Locator) to work out what the %LABEL% needs to be. Other than that, it's using javax.management.MBeanServerConnection to find and invoke the appropriate method on the MBean.
The application distribution is available here. The Java code is included in the JAR. I have also included all dependent JARs in the distribution (so it's rather large).
The application is offered as is. It is not a tool offered formally by Oracle.