Index Changes
This is version 2. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Building a composite management message response when target=cluster

The facade MBeans for target=cluster perform the requested management operatiion on each and every instance in the clsuter. For example the Installer facade MBean, when asked to install a component via the install() operation, calls the install() operation on the component Installer MBean registered in each and every instance in the cluster. If component installation fails on all the instances, the facade Installer MBean has to compose a single management message response from the individual instance responses and return that to the client ( via the exception path ).

The standard JBI management message does not have extensibility elements, which could have been used to add the "instance name". This would help the end user know which instance threw what exception. The management runtime had to use a workaround to insert the "instance name" into the composite response.

Before I go into the details of what the work around is, a few details on how a facade MBean for target=cluster creates a composite response. When a management operation is invoked on an instances JSR 208 management Mbean the operation will respond with a management message in case the task was a success ( albeit partial ) or throw an exception, with the exception message being a management message. For example if we have a cluster with two instances and a service assembly deployment operation succeeds on one instance and fails on another, then the composite response to the client would be a partial deploy success message with a warning indicating that deploy failed on the second instance. This is how the facade MBean builds this composite response :

The management response from both the instances are processed and a new management message is created with new elements as follows :

  1. The task result is derived from
    • The task result from each of the messages
    • The operation
  2. The task status messages from the framework task result in each of the two messages is extracted.
  3. The exception infos from the framework task result in each of the two messages is extracted.
  4. A new framework task result is created and the extracted task status messages and exception info are added to it.
  5. The component task results from each of the messages is extracted and added to the new management message. There is a single component task result for each component, which has the individual task status message and/or exception infos from each instance grouped under it.

There is one shortcoming in the above: the response is ambiguous. It is difficult to tell which task status message / exception info belongs to which instance.

To over come this we decided to add "marker" task status messages and exception-info to the message which would bear the instance name. The msg-loc-info within these would be as follows :

msg-loc-info/loc-message="instance name"

An instance "marker" status message / exception info will preceed the task status message / exception info specific to the instance in a framework component task result.

An example of the ant task output after making this change is :

Test Case : 

Deploy a service assembly targeted to two components to a cluster. 
The cluster has two instances. One of the test component throws an exception on service unit deploy. 
So the end result is that the service assembly is partially deployed to both instances, and  the net 
response is  a SUCCESS w/ WARNING message.  Marker "instance" task status messages are added to the 
framework result and the component task result. The ant task output is as follows : 

Service assembly deployment partially succeeded. [
   (JBIMA0404)Deployment of service assembly esbadmin00089-sa succeeded partially; some service units failed to deploy.
   (JBIMA0404)Deployment of service assembly esbadmin00089-sa succeeded partially; some service units failed to deploy.
 Component: manage-binding-1
     (JBIWHOOPS)SU deploy failed
     (JBIWHOOPS)SU deploy failed 

This is work in progress, the client code will format this message to seggregate the instance specific responses further.

This would currently break tests for cluster targets, the reference files for the broken tests need to be updated, since this is work in progress and the common client will be further formatting the messages, it is recommended that to fix the tests only once after the common client changes are done.

JSPWiki v2.4.100
« Home Index Changes Prefs
This particular version was published on 27-Feb-07 18:13 PM, -0800 by JBIWIKI