| Author |
Message
|
| JYama |
 Posted: Thu Nov 01, 2007 8:38 pm Post subject: When does a broker read BrokerDB? |
 |
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Hi, all,
Does anybody know when a broker reads its brokerDB?
I know brokerDBs hold complete information about message flows deployed, but when does the broker read it?
What happens if the brokerDB stops during a message processing?
I'm using WMBv6 on AIX, BTW.
Many thanks in advance,
Regards, |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Thu Nov 01, 2007 9:15 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
|
| Back to top |
|
|
| JYama |
| Posted: Thu Nov 01, 2007 9:27 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Thank you so much for the link, elvis_gn. 
Now I understand the timing when a broker reads its brokerDB.
I have one more question.
According to this information you gave, it seems that a broker doesn't require brokerDB once it successfully started because the broker doesn't read the DB any more.
Does this mean that the broker doesn't detect any errors related to brokerDB? |
|
| Back to top |
|
|
| rajmq |
| Posted: Fri Nov 02, 2007 1:53 am Post subject: |
|
|
Partisan
Joined: 29 Sep 2002
Posts: 331
Location: USA
|
Unless if there is no issue with broker existing process (like bip,dataflowengine..etc) so broker can run without database.
What is the reason to stop the broker database? but general recommendation is you have to keep the broker & database in the same box.
_________________
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified System Administrator - WebSphere Business Integration Message Broker V6.0 |
|
| Back to top |
|
|
| JYama |
| Posted: Fri Nov 02, 2007 5:51 am Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| rajmq wrote: |
Unless if there is no issue with broker existing process (like bip,dataflowengine..etc) so broker can run without database.
What is the reason to stop the broker database? but general recommendation is you have to keep the broker & database in the same box. |
Well, actually I'm thinking about administration in particular error monitoring like error detection by Tivoli.
What I've learned from your information is that the broker can keep running even if the brokerDB suddenly stops. Thus I understand this situation is not urgent in terms of system administration.
BTW, I agree with you that broker&brokerDB should be running together but brokerDB doesn't affect the broker's behavior. 
Thank you very much for your help.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 02, 2007 2:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JYama wrote: |
Thank you so much for the link, elvis_gn.
Now I understand the timing when a broker reads its brokerDB.
I have one more question.
According to this information you gave, it seems that a broker doesn't require brokerDB once it successfully started because the broker doesn't read the DB any more.
Does this mean that the broker doesn't detect any errors related to brokerDB? |
Not quite. Any time the broker needs to load / reload a flow into the eg it will need to access the DB...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Nov 03, 2007 3:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, DB is heavily used with pub/sub.
Leave the DB running and accessible at all times. There's no reason to risk a production outage over something like this.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JYama |
| Posted: Sat Nov 03, 2007 7:45 am Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| fjb_saper wrote: |
| Not quite. Any time the broker needs to load / reload a flow into the eg it will need to access the DB... |
Could you elaborate on that, please?
I guess, since at least one message flow instance(thread) will be initially invoked to get ready to 'MQGet' incoming messages, all information in the DB needed by the flow should be read first. Thus I thought, apart from Pub/Sub, any brokers didn't need to read the DBs after they successfully started... 
I'm confusing... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 03, 2007 11:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JYama wrote: |
| fjb_saper wrote: |
| Not quite. Any time the broker needs to load / reload a flow into the eg it will need to access the DB... |
Could you elaborate on that, please?
I guess, since at least one message flow instance(thread) will be initially invoked to get ready to 'MQGet' incoming messages, all information in the DB needed by the flow should be read first. Thus I thought, apart from Pub/Sub, any brokers didn't need to read the DBs after they successfully started...
I'm confusing... |
The broker decides on it's own how many instances of a flow to keep in memory and when to reload a particular flow into memory. Due to memory management I could even see a particular flow (inactive) being completely offloaded until needed. There is just no good reason to cut a broker from its DB. When ours were cut (dev) because the DB passwd had expired, the brokers stopped functioning properly after a while. Of course bouncing the broker made it worse until the passwd problem was fixed...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Nov 03, 2007 2:49 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| There is just no good reason to cut a broker from its DB. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Sun Nov 04, 2007 5:55 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
Hi JYama,
In terms of your original question, which I think is related to whether the broker DB should be monitored...? Yes, indeed, and an alert should prompt immediate action by your DBA team (in both production and development).
The way we use brokers in our shop, there is very little runtime access by the brokers to the database. Back in the v2.1 days, I do remember the occasional interaction with the database to record a rollback, but it was very rare. I've had a couple of situations lately where the DB cluster did not fail over the broker DB properly, but the brief interruption in service luckily did no harm.
On the larger question that evolved in this thread, about whether there is ever a good reason to cut a broker from its DB, I agree that in the world of Perfect Business Practice it should never happen.
But in my world, I sometimes assess the risk of allowing an interruption of DB connectivity versus the impact of bringing down several hundred developers/testers, and I decide to take the chance. Every such decision is a risk.
Just thought I would share my perspective, not trying to disagree about the right way to do things.
Shirley |
|
| Back to top |
|
|
| JYama |
| Posted: Sun Nov 04, 2007 5:07 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Thank you very much for powerful info and experience, all
I really appreciate it.
I've decided to monitor both DB and Broker.
Brokers and its DBs should work with even the brokers can 'temporarilly' work without DB access.
Regards, |
|
| Back to top |
|
|
|
|
