This is part of the larger task of developing Configuration Manager Proxy (CMP) applications.
GregorianCalendar oldCCTime = b.getTimeOfLastCompletionCode(); b.setLongDescription(newDesc); GregorianCalendar newCCTime = oldCCTime; while ((newCCTime == null) || (newCCTime.equals(oldCCTime))) { newCCTime = b.getTimeOfLastCompletionCode()); Thread.sleep(1000); } CompletionCodeType ccType = b.getLastCompletionCode(); if (ccType == CompletionCodeType.success) { // etc. }
In this example, the application initially determines when an action on the broker was last completed, using the getTimeOfLastCompletionCode() method. This method returns the time that the topology last received a completion code or, if no return codes have been received, a null value. The application attempts to update the broker's LongDescription and then continually monitors the topology waiting for the results of the setLongDescription() command to be returned to the CMP. When this occurs, control breaks out of the while loop and the last completion code is determined.
As well as being unsuitable for a multi-threaded application, this algorithm for determining the outcome of commands is inefficient as it causes the CMP application to wait while the Configuration Manager processes the request.
A better way of doing this is to make use of administered object notifications; see Checking the results of broker domain management using the Configuration Manager Proxy with object notification.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ae33080_ |