| Author |
Message
|
| akil |
 Posted: Fri Aug 28, 2015 7:05 am Post subject: IIB9: Failed Deployment, URL's Unregistered |
 |
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
On 9.0.0.2, we've noticed the following :
# take an execution group, with some HTTPInput node flows deployed (all flows use the broker wide listener)
# run mqsideploy with a BAR file that fails (say ESQL file incorrect or JDBCProvider not found)
At this stage, one would expect that the command would either roll-back completely or stop the message flows completely.
Instead the command leaves the broker in the following state:
# message flows are shown as deployed & running
# the URL registrations ( as reported by mqsireportproperties IB9NODE -e EG -o HTTPConnector ) are no longer present.
Clients keep getting a 404, while mqsilist shows all is fine..
Is this the expected behaviour or some bug?
_________________
Regards
Last edited by akil on Fri Aug 28, 2015 7:32 am; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Aug 28, 2015 7:09 am Post subject: Re: IIB9: Failed Deployment, URL's Unregistered |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akil wrote: |
At this stage, one would expect that the command would either roll-back completely or stop the message flows completely.[
Instead the command leaves the broker in the following state:
# message flows are shown as deployed & running
# the URL registrations ( as reported by mqsireportproperties IB9NODE -e EG -o HTTPConnector ) .
Clients keep getting a 404, while mqsilist shows all is fine.. |
So you're saying that you take an execution group, attempt to deploy an entirely new flow with an HTTPInput node, this attempt fails but the flow shows as deployed and running in the execution group and the URL in the HTTPInput node shows as registered?
As distinct from deploying a new version of a previously deployed flow that fails to deploy for one of the reasons specified?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| akil |
| Posted: Fri Aug 28, 2015 7:11 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
Sorry, I should have specified it clearly, I am re-deploying the same flows once again. Not a new flow.
_________________
Regards |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 28, 2015 7:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akil wrote: |
| Sorry, I should have specified it clearly, I am re-deploying the same flows once again. Not a new flow. |
| akil wrote: |
| At this stage, one would expect that the command would either roll-back completely or stop the message flows completely. |
So the deploy command fails, the deploy command is rolled back and you're surprised to see the previous versions of the flow running and with their URL registered? You don't expect the roll back of the deploy command to restore the previously deployed flows to the state they were in before the now-aborted deploy command tried to alter them?
| akil wrote: |
| Is this the expected behaviour |
I would absolutely expect the flows to be in the state they were in before I tried unsuccessfully to deploy over them. I don't know why you expect anything different.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| akil |
| Posted: Fri Aug 28, 2015 7:33 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
The flows remained (good), but the URL registrations disappeared (not good).
This resulted in clients getting a 404.
The support team just checks mqsilist , and they said all is fine ..
It took some time to figure out that while the flows were shown, the URL registration were no longer present ..
_________________
Regards |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 28, 2015 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akil wrote: |
| It took some time to figure out that while the flows were shown, the URL registration were no longer present .. |
Missed that in your original post (must be Friday) 
That's a bug. You should raise a PMR.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 28, 2015 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
FWIW it works great in my copy of IIBv9.0.0.2 using an EG-level listener.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Aug 28, 2015 8:11 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I tend to deploy the new flow releases into a different EG leaving the original flow where it was but stopped.
We have an EG called PR_1. This is where all new releases get deployed. If things go wrong (and to err is Human) we can switch back to the previous versions in a few seconds.
If all goes well for 24 hours the flow is moved to its proper EG.
Yes we have tested everything beforehand but we insitgated this system because despite ssurances that the Barfileoverrides had been done, they had not and we deployed a flow to prod that was for another site.
{This is also one of the reasons why I don't like using barfile overrides}
The above procedure avoids the problems that the OP has encountered. Needless to say this only works with HTTP flows when the broker wide HTTP Listener is used and not at all for SOAP flows. Still, you can't win them all.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 28, 2015 8:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| and not at all for SOAP flows |
Unless you tell them to use the biphttplistener too.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| akil |
| Posted: Fri Aug 28, 2015 10:38 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
| Vitor wrote: |
| FWIW it works great in my copy of IIBv9.0.0.2 using an EG-level listener. |
This EG used the broker wide listener ..
Will try with the eg listened as well.
_________________
Regards |
|
| Back to top |
|
|
|
|
