| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Broker deploy problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| anirudh |
 Posted: Wed Feb 19, 2003 9:37 am Post subject: Broker deploy problem |
 |
|
Newbie
Joined: 19 Feb 2003
Posts: 4
|
Hi,
I am newbie to WMQI and am facing some problems.
I am using WMQI 2.1 & WMQ 5.3 with DB2 7.1 as the repository.
Now ,when I try to deploy the broker using the Complete Configuration
option the deploy seems to fail totally.As per documentation there is a
Stage I and a Stage II in the deployment process.Success in each
stage will give logs in the log pane ,but none seem to appear.The log
pane is configured to log all levels.
Further, I tried analysing the failure using the instructions in chapter 4
of the "Problem determination guide" under the heading -->>"Has a communication problem stopped the deployment message?"
Now as per this doc I found out that the channel connection between
config manager's queue manager & the broker's queue manager
is working fine(This is odd because that means Stage I should have
succeded)
but the reverse channel(i.e. from the broker to queue manager) does
not work.
Any suggestions or help as to how I should proceed further will be deeply
appreciated.
Thanks,
Anirudh |
|
| Back to top |
|
 |
| philip.baker |
| Posted: Thu Feb 20, 2003 12:04 pm Post subject: |
|
|
Voyager
Joined: 21 Mar 2002
Posts: 77
Location: Baker Systems Consulting, Inc. - Tampa
|
hi anirudh,
Based on your description, there are two queue managers involved, one for the CM (ConfigManager) and one for the Broker. One result you will get if the queue managers are clustered and you a relying on MQ clustering, is that the deploy data will go to the broker QM, but you will never get a reply message back to the CM. This is because the queues created and used when you create a broker are not part of the cluster. (IBM advises you not to add these queues to the cluster.) If you are not trying to use MQ Clustering, you may want to configure and test your channels between the two Queue Managers involved to automatically start when a message is submitted and placed on the XMIT queue on either end. Go through the MQ setup of these channel connections carefully and make sure there are no basic MQ issues before trying a deploy to the broker.
_________________
Regards,
Phil |
|
| Back to top |
|
|
| anirudh |
| Posted: Thu Feb 20, 2003 8:33 pm Post subject: |
|
|
Newbie
Joined: 19 Feb 2003
Posts: 4
|
Thanks Phil for your reply , the problem indeed was with the wrong congifuration of the channels between the broker & and configmgr. I fixed that and the broker deployed okay.
But before that I had to recreate the broker & configmgr dbs as they were out of synch with their queue mgrs and had redeploy everything again.
Is there a command which can clean up the last deploy action,remove all the messages in the queue & entries in the db?
Thanks,
Anirudh |
|
| Back to top |
|
|
| philip.baker |
| Posted: Sat Feb 22, 2003 5:19 pm Post subject: |
|
|
Voyager
Joined: 21 Mar 2002
Posts: 77
Location: Baker Systems Consulting, Inc. - Tampa
|
Well, for your situation, you could have stopped the non-working channel from the broker to the CM, enabled get on the XMIT queue and removed any messages in the XMIT Q on the broker QMGR. On the CM side, you needed to either edit the Database entry in the CBROKER table of the CM database or remove (delete) all the entries in the CBROKER table altogether.
_________________
Regards,
Phil |
|
| Back to top |
|
|
| anirudh |
| Posted: Mon Feb 24, 2003 7:01 am Post subject: |
|
|
Newbie
Joined: 19 Feb 2003
Posts: 4
|
Phil,
Is there some documentation which contain the DB schema info for
brokers , config mgrs etc. because unless I know the schema well
I could end up corrupting the system.
Also I have another question on the DB front. Is it advisable to have
1.)A single db schema for all brokers, if possible. Can we do that?
2.)Or the better option is to define a DB schema for a Collective?
Thanks,
Anirudh |
|
| Back to top |
|
|
| philip.baker |
| Posted: Mon Feb 24, 2003 11:05 am Post subject: |
|
|
Voyager
Joined: 21 Mar 2002
Posts: 77
Location: Baker Systems Consulting, Inc. - Tampa
|
anirudh,
You can have multiple brokers using the same Broker database. Database records for each broker have unique information in the record. You can also have separate databases under the same instance (DB/2) or separate databases under separate database instances. Understand there may be some issues with database terminology when talking about different database vendors. For example, when using DB/2 as your broker database, you can have multiple databases under one database instance. For Oracle, you really only have one database per Oracle instance, but you can have multiple schemas within the database. From purely a database size issue, the broker database never really gets very large, but I would still advise increasing some of the database parameters to overcome some potential performance problems. The real issue that you may see happen when using the same database for multiple brokers will have to do with concurrency issues (DB locking,etc.) if you have a lot of high activity flows. This usually occurs, however, not so much on the broker database as the application database(s) that a flow may access.
So to answer your questions:
I don't know off-hand if the table structures are in the MQSI manuals or not. I was just curious one day and ran the schemas/describes of each table .
"1.)A single db schema for all brokers, if possible. Can we do that?"
Yes, you can have multiple brokers use the same broker database (and schema). This will avoid having you create and maintain multiple databases and/or multiple database instances. However, with the good is always the bad. Since all brokers are using the same database/tables, if something happens to the database or one of the tables, it could effect all brokers. Using a separate database for each broker would avoid this.
"2.)Or the better option is to define a DB schema for a Collective? "
If you're talking about a "broker collective", I'm not sure what grouping the brokers within a certain collective will get you. Collectives of brokers are typically setup to allow the brokers direct access to each other for making pub-sub applications more efficient. The data used by each broker and stored in the broker database(s) is independent from the pub-sub application data usage.
_________________
Regards,
Phil |
|
| 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
|
|
|
|
