| Author |
Message
|
| Featherstone |
 Posted: Mon Jan 24, 2011 3:46 am Post subject: Additional Instances Setting/Getting Using CMP |
 |
|
Novice
Joined: 18 Oct 2010
Posts: 11
|
Hi, running on Windows MB 6.1.0.3 and toolkit 6.1.0.8. Trying to set the additional instances property for a message flow using the CMP java classes.
I've used the MessageFlowProxy setAdditionalInstances(instance value) function followed by a BrokerProxy deploy and when I perform a mqsireportproperties I can see the additonal instances is set to the new value.
This would all make sense as the 6.1.0.8 help for the setAdditionalInstances functions says:
| Quote: |
| Attempts to ask the broker to directly set the value of the Additional Instances property for this message flow. Any changes to this the runtime property are not reflected in the getAdditionalInstances() return value, which only returns the value of the property as it was originally deployed. After calling this method, call BrokerProxy.deploy() to enable the setting on the broker. |
The important bit is the 'Attempts to ask the broker directly'.
This is all OK but if you look at the broker topology in the Domain Connection window of the toolkit you will see the ORIGINAL value
as used in the last deployed BAR file. This could introduce confusion as you have a mismatch in between the value on the config manage and the broker!
My second attempt was to use the setRuntimeProperty(NAME_ADDITIONALINSTANCES) function as the help says:-
| Quote: |
Asks the Configuration Manager to configure an arbitrary message flow property.
After calling this method, getParent().deploy() needs to be called in order to deploy the changed configuration to the broker. It is possible to change multiple runtime properties and invoke the deployment just once at the end. |
My understanding of this is that the Config Manager is modified and the change then propagated to the broker by the deploy(). If this was the case then I would expect the broker topology in the toolkit to show the new value - IT DOESN'T !
Can someone enlighten me as to how I can ensure that the value of the instances is maintained in step on both the =config mgr and broker ?
NOTE:-
Doing the setAdditionalInstances in MB 7 shows the updated additional instances value for the floe in the toolkit - this is probably because under MB7 there is NO config manage so the topology is directly connecting to the broker for it's status etc. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jan 24, 2011 3:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The ConfigMgr resynchronizes it's view of a Broker every hour or so. So I suspect that your concern about using setAdditionalInstances is overstated. After synchronization, the Toolkit view should show the new value, afaik.
Otherwise, mqmatt will be along in a bit I'm sure. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Mon Jan 24, 2011 4:39 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
| The toolkit does not show the new value. It is not expected to so synchronisation won't help. I cannot remember the reason behind it. |
|
| Back to top |
|
|
| Featherstone |
| Posted: Mon Jan 24, 2011 5:05 am Post subject: |
|
|
Novice
Joined: 18 Oct 2010
Posts: 11
|
| I can confirm that the synchronization does not reflect back in the toolkit. I updated my Java to perform a discoverConfiguration() rather than waiting the 60 minutes. |
|
| Back to top |
|
|
| mqmatt |
| Posted: Mon Jan 24, 2011 5:12 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
In V6.1, the getAdditionalInstances() method returns the value of the additional instances parameter as originally deployed, and this is what the toolkit uses.
In that version, calling setAdditionalInstances() followed by BrokerProxy.deploy() is a bit like running mqsichangeproperties... It alters the value on the broker, but doesn't change the original value stored by the ConfigMgr.
However, you should be able to see the new value in the CMP/ConfigMgr by reviewing the (synchronised) runtime properties (i.e. getRuntimeProperty()).
(It's been a while since I looked at V6.1 so apologies if I've misremembered.)
In V7, because there is no ConfigMgr there is only one copy of the additional instances parameter per message flow*-- and this contains the current active value. This value is returned through getAdditionalInstances() and set using setAdditionalInstances(). Though you can continue to use getRuntimeProperty() and setRuntimeProperty() if you wish.
* Hmm.. not entirely true, as you can have an additional instances parameter at the node level. But that's a completely different setting. |
|
| Back to top |
|
|
| Featherstone |
| Posted: Mon Jan 24, 2011 5:44 am Post subject: |
|
|
Novice
Joined: 18 Oct 2010
Posts: 11
|
You are correct in that the getRuntimeProperty(NAME_ADDITIONALINSTANCES) returns the new value.
Likewise, I was also coming to the conclusion that the toolkit must use the getAdditionalInstances() function...
Thankyou for confirming my thoughts on this subject. I suspect our support team may not be too happy in what they see (in the toolkit) does not always mirror the live production environment.... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 24, 2011 5:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Featherstone wrote: |
You are correct in that the getRuntimeProperty(NAME_ADDITIONALINSTANCES) returns the new value.
Likewise, I was also coming to the conclusion that the toolkit must use the getAdditionalInstances() function...
Thankyou for confirming my thoughts on this subject. I suspect our support team may not be too happy in what they see (in the toolkit) does not always mirror the live production environment.... |
They need to balance this unhappiness against the benefit gained from adjusting the additional instances without doing a new deploy.
And migrate to v7...  |
|
| Back to top |
|
|
| Featherstone |
| Posted: Thu Jan 27, 2011 4:15 am Post subject: |
|
|
Novice
Joined: 18 Oct 2010
Posts: 11
|
A final note on this...
Be aware that a deploy using a BAR file doesn't update all of the information about a broker that is held on the config manager. An example is the additional instance value of a flow.!
To demonstrate this, after deploying a flow to an ex grp for this first time and then issuing a CMP getRuntimeProperty for the additonal instances of that flow will return a value of NULL. The toolkit will show the flow as deployed in the ex grp but the config manager will not have the value of the additional instances until the synch happens (every 60mins, restart of the config manager or issue of a discoverConfiguration using the CMP for example) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 27, 2011 5:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| That's probably a fix-pack level specific bug. ConfigMgr should know the additional instances on the bar file, since it's what's doing the deploy. If it's not updating it's own information, then that's presumably cause for a PMR. I don't know that it's worth the effort of a PMR, however, especially as moving to v7 will eliminate the issue anyway. |
|
| Back to top |
|
|
|
|
