| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Delaying DeployResult |
« View previous topic :: View next topic » |
| Author |
Message
|
| petmor |
 Posted: Fri Dec 28, 2007 4:46 pm Post subject: Delaying DeployResult |
 |
|
Apprentice
Joined: 20 Jun 2002
Posts: 45
Location: Pasadena, CA
|
Hi,
I'm using the WMB 6.0 CMP Java API to deploy .bar files to WBI5 and WMB6 brokers. The ExecutionGroupProxy deploy() method works well, but I generally always receive a "submitted" return when calling the DeployResult getCompletionCode() method. I have tried using the DeployResult setDeployResultReturnTimeDelayMs() method to delay the return, but I must be using it incorrectly, because my deploy requests still return "submitted". I would expect to see "success" or "failure", as I am delaying 15000 milliseconds (15 seconds). The code where I try delaying the return is pasted below. What am I doing wrong?
public DeployResult deployBar(ConfigManagerProxy cmp, ExecutionGroupProxy eg, String bf, String tf, long to, long intrvl)
{
DeployResult dr = null;
try {
cmp.enableConfigManagerProxyTracing(tf);
dr.setDeployResultReturnTimeDelayMs(intrvl);
dr = eg.deploy(bf, true, to);
Thread.sleep(intrvl);
}
catch (ConfigManagerProxyLoggedException cmpLE) {
cmpLE.printStackTrace();
}
catch (IOException ioEX) {
ioEX.printStackTrace();
}
catch (InterruptedException iE) {
iE.printStackTrace();
}
return dr;
}
Thanks!
Peter |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sat Dec 29, 2007 8:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Moved to WBIMB / WMB forum.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Dec 29, 2007 11:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You'll likely either have to go back to the samples and see what's up, or wait for mqmatt to come back from holidays.
I've not worked with CMP at all, so I can't really suggest anything else.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 29, 2007 4:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried with 30 seconds? I believe that most manuals and hints to the -w flag mention 30 seconds. Maybe 15 seconds is just not enough... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqmatt |
| Posted: Wed Jan 02, 2008 4:02 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Hi there,
The setDeployResultReturnTimeDelayMs() method is not the timeout you're looking for, you probably need to increase the value of the timeToWaitMs parameter ('to' in your example) instead.
Let me have a bash at explaining why. In order for a deployment to successfully complete, the CMP needs a response from both the Config Manager and the broker. The CMP waits for the period of time specified by the timeToWaitMs parameter on the deploy method before returning a DeployResult object.
You can tell what happened by looking at the DeployResult:A 'submitted' value means that (in this time) neither the CM nor the broker responded.
A 'initiated' value means that the CM responded but the broker did not.
A 'success' or 'failure' value means that both the CM and broker responded. Only if both components have sent a response, the CMP can optionally wait for an additional length of time, set using setDeployResultReturnTimeDelayMs(). This is because a broker may send back multiple responses to the same deployment (e.g. both a BIP4040 and a BIP2056), and we want the CMP to report both of these messages in relation to the current deploy.
Hope this helps. In short:
timeToWaitMs: time for the broker and CM to respond (to get back a 'success' rather than 'submitted' response)
setDeployResultReturnTimeDelayMs: time to see if any more messages come back from the broker once a 'success' or 'failure' response is ready to be reported.
-Matt |
|
| Back to top |
|
|
| petmor |
| Posted: Wed Jan 09, 2008 3:17 pm Post subject: |
|
|
Apprentice
Joined: 20 Jun 2002
Posts: 45
Location: Pasadena, CA
|
Hi Matt,
Turns out I was mistakenly passing a long 'seconds' value instead of long 'milliseconds' value to the deploy() method. I pass 20000 now and the DeployResult object now has a useful return. Thanks for your reply. It prompted me to study the API a little more closely.
I have one other question. Does a return of 'success' indicate that the .bar deployed successfully, or merely that both Config Mgr and Broker replied? I am guessing the latter. Does using setDeployResultReturnTimeDelayMs() therefore enable getCompletionCode() to report an error BIP message if there was bad ESQL in the .bar for example?
Thanks also to everyone else who replied to my post!
Peter |
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Jan 10, 2008 3:30 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
| petmor wrote: |
| Does a return of 'success' indicate that the .bar deployed successfully, or merely that both Config Mgr and Broker replied? I am guessing the latter. |
No, the 'success' return code means that the broker successfully deployed the message flows and is running them (i.e. you got BIP4040, BIP2056 etc.).
If the broker had sent a response but had rejected the deployment, then the return code would have been 'failure'.
| petmor wrote: |
| Does using setDeployResultReturnTimeDelayMs() therefore enable getCompletionCode() to report an error BIP message if there was bad ESQL in the .bar for example? |
That method only allows more than one message to come back from the broker, because it sets the time to wait *after* the first message comes back from the broker (to see if more messages are sent by the broker). If the deploy failed, then regardless of the value you set in setDeployResultReturnTimeDelayMs(), the return value will still be 'failure'. It's just that slightly less information may be supplied.
If the ESQL was syntactically incorrect, the toolkit shouldn't let you deploy it in the first place. If the errors are semantic ones, deploys will probably work OK and the deploy will return success anyway.
Cheers
-Matt |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
