| Author |
Message
|
| inMo |
 Posted: Wed Apr 04, 2012 11:48 am Post subject: User Defined Configurable Services Cache |
 |
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
Is anyone aware of how the broker deals with a User Defined Configurable Service? I am interested in understanding how the configuration is made available to the flow for use.
This is not a coding question, rather, it is a resource management question and how that mangement impacts performance. Is the User Defined Configurable Service initially retrieved from a file or broker memory? Would storing the retrieved configuration in a shared variable on the flow's first run provide a performance improvement for subsequent messages, or is the configuration already cached by the broker? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Apr 04, 2012 12:00 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The data is stored in $MQSI_WORKPATH/components/<brokername>/repository in a flatfile.
Changes to Configurable Service objects sometimes require restarts. Prior to a restart, some info can be stale.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| inMo |
| Posted: Wed Apr 04, 2012 12:07 pm Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
Thanks for the response, I'll take a peak.
Does that mean that the configuration stored in the flatfile is re-read every time the flow runs? In my experience, changes to a Configurable Service require an EG restart in order for the flow to recognize the change. That to me suggests the broker or EG is caching the configuration vs. going to the flat file each time. I just can't find any discussion on this topic, and would like to consider the performance implications of leveraging a User Defined Configurable Service. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Apr 04, 2012 12:10 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
Changes to Configurable Service objects sometimes require restarts. Prior to a restart, some info can be stale. |
A good practice is to ALWAYS restart after creating or changing Configurable Services, ODBC Configs or any Broker/EG wide settings( EG Reload is good here).
This way there can be no doubt as to which operation requires a restart.
If you automate it, you can add an extra step between the stop and the start...
You know it makes sense....
_________________
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 |
|
|
| lancelotlinc |
| Posted: Wed Apr 04, 2012 12:12 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
mqjeff or mgk may have better knowledge than I. My understanding is these files are read at startup time and only re-read when a flow deployment happens or on a restart.
Performance between built-in Configurable Services (mqsisetdbparams to configure db settings) and User-defined Configurable services are similar, since my understanding is, WMB writes the same info to files in that directory.
I'm not sure what you are driving at. Are you have throughput problems?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| inMo |
| Posted: Wed Apr 04, 2012 12:22 pm Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| No actual throughput problems to speak of, but that is the spirit of the question. If a flow is expecting a user defined configurable service to be loaded, does that translate to reading a file off the file system each time the flow is run? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Apr 04, 2012 12:23 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| inMo wrote: |
| No actual throughput problems to speak of, but that is the spirit of the question. If a flow is expecting a user defined configurable service to be loaded, does that translate to reading a file off the file system each time the flow is run? |
No, configurations are read once, and only once at startup, not every time a flow runs. Thats the whole point of Configurable Service, to avoid re-reading a properties file with every invocation, among other things.
Party on! "Wayne's World"
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| inMo |
| Posted: Wed Apr 04, 2012 12:27 pm Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Any suggestions on how one might prove this idea to non-believers? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Apr 04, 2012 12:37 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| inMo wrote: |
| Any suggestions on how one might prove this idea to non-believers? |
The proof is in the pudding. Spend two hours, create a configurable service, drop 12 million msgs in a queue that hits it. The MB Explorer can be used to define and manage broker configurable services. The SAP adapter properties can be configured outside the main adapter definition, using configurable services. Properties such as the host name, client ID, system number, user ID and password can now be specified in a configurable service. FTP nodes can be configured with configurable service.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 04, 2012 12:54 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
As always, if you want an accurate and correct answer that you can use to convince other people, you should a) review the Info Center, b) open a PMR.
Yes, *all* configurable services are read at EG startup, and not again.
Easy way to test this is to use a User Defined Configurable Service to hold a queue name. Then use the queue name as an output of an MQOutput message. Then start the EG, run a bunch of messages through. Then change the User Defined Configurable Service to another queue - but DO NOT restart the EG.
The Configurable Service will list a different queue, but the flow will keep using the original version - until you restart the EG. |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Apr 04, 2012 1:05 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| The Configurable Service will list a different queue, but the flow will keep using the original version - until you restart the EG. |
This is only true until V8. In V8 come configurable services (including user defined ones) have been changed to pick up changes dynamically (between message invocations) when changes are made.
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Apr 05, 2012 12:20 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
I have implemented a user defined configurable service cache for a customer. But if the properties of the service are changed, the eg must be restarted. That will refresh the cache as well, which is nice.
I was a bit puzzled about what to do with the cache in version 8 when the eg will automatically refresh configurable services. Should I implement some kind of listener that would refresh my cache every time the eg does a refresh?
I discussed the problem with mqmatt in Berlin and got a very valuable hint. Configurable services are fetched from the local broker and this happens very fast. The only thing that takes time is when you open the connection to the Broker. Also it does not make much sence to cache configurable service data. The only thing you will need to cache is the BrokerProxy object that encapsulates the connection.
And this applies to version 7 as well. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Apr 19, 2012 11:28 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
mgk - Updating the running configurable services values immediately between message flow invocations is risky - because there might be several admin changes needed at the same time and the administrator would be unable to control the timings of the updates.
I would prefer to make all my WMB changes, verify that they they look right by displaying them, and then activate them in a deliberate, controlled manner, all at the same time, with a mqsireload.
I think it is potentially asking for trouble to allow them to change immediately and individually - in effect uncontrollably. In an operational sense issuing mqsireload is not a problem. A broker restart is, of course, highly undesirable. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Apr 19, 2012 11:42 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| venkataratna wrote: |
| how to Create different configurable services for generic user in websphere 6.1 version |
Fortunately MB V 6.1 does not have user defined configurable service, so this is no can do.
Why do I say fortunately? Because in 6.1 CMP calls go via the Configuration Manager, and if you did CMP calls from your flows that would make the broker runtime too dependent on the availability of ConfigMgr and thus your environment vulnerable. I would not recommend it.
I am not sure if I understand what you mean. But I think you have thes options:
- create an external web service (on an application server)
- use a database
- use configuration queues
The last alternative is quite unreliable, but that is my personal opinion only. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Apr 19, 2012 11:47 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| zpat wrote: |
mgk - Updating the running configurable services values immediately between message flow invocations is risky - because there might be several admin changes needed at the same time and the administrator would be unable to control the timings of the updates.
I would prefer to make all my WMB changes, verify that they they look right by displaying them, and then activate them in a deliberate, controlled manner, all at the same time, with a mqsireload.
|
I think this is a welcome change. You just need to rethink your administration routines. What about just stopping the flows before making changes to configurable services? |
|
| Back to top |
|
|
|
|
