| Author |
Message
|
| zpat |
 Posted: Fri Oct 26, 2012 1:33 am Post subject: What's needed to pick up a change to a configurable service? |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I need to modify the destination address for a file transfer (fileoutput node), which uses a configurable service definition. So I will issue a command like
mqsichangeproperties BROKER -c FtpServer -o OBJECTNAME -n serverName -v newaddress.xxx.com
What I need to know, is the least disruptive (most granular) action that will cause the flow to start using the new value?
Is it restarting the flow? Or restarting the EG? Or reloading the EG, Or restarting the Broker?
WMB 6.1.0.8 on AIX |
|
| Back to top |
|
 |
| marko.pitkanen |
| Posted: Fri Oct 26, 2012 2:13 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
If I got it right InfoCenter it says
| Quote: |
Before you run the mqsichangeproperties command, ensure that the broker is running.
If you change one or more values, stop and start the broker again for the change to take effect.
When a message flow that includes HTTP nodes is started, the broker starts the HTTP and HTTPS listeners, unless this listener has been disabled.
|
Perhaps it depends on what properties you change.
I have noticed that mqsireload for EG works for the most cases including this FON destination server address at least with 7.0.0.4
--
Marko |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Oct 26, 2012 2:36 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
| marko.pitkanen wrote: |
Perhaps it depends on what properties you change.
I have noticed that mqsireload for EG works for the most cases including this FON destination server address at least with 7.0.0.4
--
Marko |
Although in the past I have seen issues when a simple flow restart should have reset values but have had to take it up a notch to EG and once or twice to Broker.
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 26, 2012 2:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, I have now tested it with a simple flow and the answer is all four actions will pick up the change to the server address.
In other words, it can be granular. |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Oct 26, 2012 3:48 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Thats interesting. I had always through that an EG restart was required to reload any Configurable Service properties (I assumed that the EG cached all the defined CS settings on startup). Thanks for the heads up. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 26, 2012 4:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| McueMart wrote: |
| Thats interesting. I had always through that an EG restart was required to reload any Configurable Service properties (I assumed that the EG cached all the defined CS settings on startup). Thanks for the heads up. |
I assume that this behavior improves as one increases in version number.
I assume that it's not a terribly hard thing to do to have mqsichangeproperties invalidate the cached entry for a configurable service. |
|
| Back to top |
|
|
| Esa |
| Posted: Fri Oct 26, 2012 4:32 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
I assume that this behavior improves as one increases in version number.
I assume that it's not a terribly hard thing to do to have mqsichangeproperties invalidate the cached entry for a configurable service. |
It's not that simple. I guess there are many existing applications that rely on the fact that the cache is only refreshed when the EG is restarted. You cannot make that kind of a major change in the behavior just like that in a fixpack, can you?
V8 refreshes the cache immediately. That means problems for organisations that have taken advantage of the current behaviour. They will have to migrate, if not necessarily the flow implementations, at least their way of working.
I think it was zpat that pointed this out in some discussion last Spring. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 26, 2012 5:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| You cannot make that kind of a major change in the behavior just like that in a fixpack, can you? |
As I am frequently reminded, I can't make any changes in any behavior at all... somehow, apparently, it's not actually *my* job to do that. |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Oct 26, 2012 6:01 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
|
| Back to top |
|
|
| joebuckeye |
| Posted: Fri Oct 26, 2012 6:29 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Esa wrote: |
| It's not that simple. I guess there are many existing applications that rely on the fact that the cache is only refreshed when the EG is restarted. You cannot make that kind of a major change in the behavior just like that in a fixpack, can you? |
I can imagine it depends on whether or not the behavior being counted on is documented to work a certain way or if it just happens to work that way and people count on it.
Sort of like people complaining about the XMLNSC parser "causing" errors while the XML parser works fine. |
|
| Back to top |
|
|
|
|
