|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Assert qm exsit? |
« View previous topic :: View next topic » |
Author |
Message
|
Vitor |
Posted: Wed Dec 03, 2008 1:02 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fjb_saper wrote: |
This looks very much like a cluster setup to me. Otherwise you'll soon be dying under the load of just simple channel definitions. |
There also doesn't seem to be any control mechanisms in here. How do you apply software to an unknown number of queue managers? Or is the number of possible machines fixed? If so, how do you prevent more queue managers on a given machine than the resources will permit?
I also don't see an answer to my question about moving dev->test->prod. This may be because of the issue with English (and I should point out your command of English is much better than my command of any other language!).
A key part of my role is "fixing" WMQ when developers claim it's not working; normally when a message they're expecting doesn't turn up where they expect. How do you find & resolve such routing errors? Or locate non-running channels? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zlj |
Posted: Wed Dec 03, 2008 5:28 pm Post subject: |
|
|
 Apprentice
Joined: 13 Nov 2008 Posts: 32
|
Vitor wrote: |
How do you apply software to an unknown number of queue managers? |
I have only one queue manager, but I have lots of message queue at server. When server need a new one(queue), client do install IBM MQ already, config server ip address, server QM's name which is fixed and fixed server local queue name etc. Once server change any attribute of QM/MQ, client will know it through datatbase. Any info about message queue will store in DB or application config files. Any change will notify to each other, config apllication will manage it.
EG:
1.new client created, after install MQ product, open config application I supported. config application will create QM, local queue, receive channel automatic with the naming rule. Then client set server ip, according to the naming rule I am already know the QM name and channel name of server.
2.Some one(client worker) tell Server they are ready, then give the info(ip,client name) to server. Server know the channel name and client MQ name etc. according to the naming rule another time.
3.Test it, ensure it is going well, What I do is making all of this possible. If some thing out of control(it does not work well) MQ admin needed now!
Vitor wrote: |
If so, how do you prevent more queue managers on a given machine than the resources will permit?
|
Security? We are thinking about.
Vitor wrote: |
I also don't see an answer to my question about moving dev->test->prod.
|
Does it mean devlopment-->test my application-->what is prod?
Vitor wrote: |
I should point out your command of English is much better than my command of any other language!
|
Thank you!
Vitor wrote: |
A key part of my role is "fixing" WMQ when developers claim it's not working;
|
WMQ means? We need one or two MQ admin as you, but we do not need the same number MQ admin as clients number.
Vitor wrote: |
normally when a message they're expecting doesn't turn up where they expect. How do you find & resolve such routing errors? Or locate non-running channels? |
We ensure config application going well or change my application to be well. Any error we do not expected client/server user will notify MQ admin service, MQ admin and me(config application developer) will trace the error, and then update config application, next roll back operation, at last redo it with uodated config application.
I am wondering am I describe clearly? |
|
Back to top |
|
 |
zlj |
Posted: Wed Dec 03, 2008 5:39 pm Post subject: |
|
|
 Apprentice
Joined: 13 Nov 2008 Posts: 32
|
fjb_saper wrote: |
This looks very much like a cluster setup to me. Otherwise you'll soon be dying under the load of just simple channel definitions.
However understand that unlike MSMQ in WMQ you can only GET a message that's in a QLOCAL to the qmgr you are connected to.
So this means when your customers/clients decide to connect to their own qmgr you need a pub/sub kind of mechanism for them to advertise their new "address" (qmgr name).
Creating a qmgr without any involvement of the mqadmin is inherently dangerous. If you need to change the Log type or logfilesize you need to delete and recreate the qmgr. There is no thought here about planning for sizing, type of workload, backup strategies and so forth...
 |
I do not know cluster setup well, does it mean when I finished my setup, I can not change my queue without MQ admin?
Channel changed not often, "dying under the load of just simple channel definitions." means lots of channel will overload?
We do not care about log, untill error occur, we never change it.
fjb_saper wrote: |
Trust me with the kind of environment you have, you don't want to do without MQAdmin. If you do, you'll have to pay up even more later...
|
What should I do? Do we need 1000 MQ admin for 1000 clients which in differe area and thousand miles way for wach other. I can not go there easily, and each of them have a MQ admin is not possible.
But I am scared of this words |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 03, 2008 9:07 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
From the postings you did I would say that your knowledge of MQ is not sufficient to attempt a correct configuration of what you are trying to do.
You need to enlist the help of a seasoned MQ Admin.
No you don't need an MQ Admin for each of the 1000 clients. However I would strongly suggest that you get one to administer the MQ Network.
The MQ Admin can also work on remote qmgrs. This is why we have the internet and tools like putty, ssl and crypto suites, and sometimes hated network and firewall admins.
Quote: |
Channel changed not often, "dying under the load of just simple channel definitions." means lots of channel will overload? |
No, this means that every time the MQ Admin creates a new qmgr, he/she will need to create the connections to all other qmgrs in the network. This is a lot of work. Using MQ clusters reduces these definitions by an order of magnitude.
Imagine your MQ network has 50 qmgrs. To add a 51st qmgr you need to define 100 channels if not clustered versus only 2 if clustered...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
zlj |
Posted: Wed Dec 03, 2008 10:51 pm Post subject: |
|
|
 Apprentice
Joined: 13 Nov 2008 Posts: 32
|
fjb_saper wrote: |
From the postings you did I would say that your knowledge of MQ is not sufficient to attempt a correct configuration of what you are trying to do.
You need to enlist the help of a seasoned MQ Admin.
No you don't need an MQ Admin for each of the 1000 clients. However I would strongly suggest that you get one to administer the MQ Network.
The MQ Admin can also work on remote qmgrs. This is why we have the internet and tools like putty, ssl and crypto suites, and sometimes hated network and firewall admins.
Quote: |
Channel changed not often, "dying under the load of just simple channel definitions." means lots of channel will overload? |
No, this means that every time the MQ Admin creates a new qmgr, he/she will need to create the connections to all other qmgrs in the network. This is a lot of work. Using MQ clusters reduces these definitions by an order of magnitude.
Imagine your MQ network has 50 qmgrs. To add a 51st qmgr you need to define 100 channels if not clustered versus only 2 if clustered...
Have fun  |
I should admit I lack of MQ experience as a new player, and sometimes I lost my way. I do admit.
The truth have to face is I am the most seasoned one about MQ in my team, although it looks funny. So we are at the beginning, and every beginning is difficult, but I am trying.
About what you said, I think I am definite to be the seasoned MQ Admin plus the firewall admins although I am not. My duty is to be the seasoned MQ Admin.
I need read about SSL, and clusters next. But we do not need clusters now, for my clients are forbide to connect each other.
Any suggestion? |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Dec 04, 2008 3:24 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Clients do not connect to each other. Qmgrs do.
The question is which way do you need to have the messages flow.
On top of this if you need pub sub and authorizations on pub /sub you need either WMB Version 6 and above or MQ V7 and above.
The rest is mostly a question of authorizations/authorization groups.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|