| Author |
Message
|
| ivanachukapawn |
 Posted: Sat Dec 23, 2006 3:50 pm Post subject: listener creation no longer supported |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I just setup a Windows only environment with MQ6.0 and MB6.0
I attempted to run the create default configuration by running the default configuration creation wizard. It was successful on most steps but got an error when attempting to create a listener (port 2414) for the default queue manager. It then gave me a choice: either correct the problem and click OK to try again, or click no and have everything backed out. I had no choice but to click no.
the error log shows:
Creating a listener for queue manager [WBRK6_DEFAULT_QUEUE_MANAGER] on port 2414.
Status ERROR: com.ibm.etools.mft.eou code=0 Could not create the listener.
Collected output from task >
Stdout: [5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
Listener creation no longer supported
Anybody know why creation of a listener is no longer supported? |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Sun Dec 24, 2006 5:41 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Dec 25, 2006 11:54 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Joseph,
OK I'll forget about creating the 'Default Configuration' using the wizard that no longer can create a listener for the QM.
But I have a question about the MQ communications using the architecture you recommended. You recommended that I create 1 queue manager and then create both configuration manager and broker to use that queue manager. What if my environment were 'production-like' in that my broker runs on an AIX system and my toolkit/config manager runs on windows. In this setup would it not be standard practice for there to be a queue manager running on windows which the configuration manager connects to and a queue manager running on AIX which the broker connects to? If using separate queue managers, is it standard practice to have these queue managers connect via sender/receiver channel pairs and to have remote queue definitions so that the configuration manager can put configuration requests on the broker's queue manager's SYSTEM.BROKER.ADMIN.QUEUE? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 25, 2006 12:30 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There is not really any "standard" practice.
Most shops do things the way that is correct for them.
A config manager needs to run against a local queue manager.
It also needs to run exactly and only where it can connect to the security registry that should be used to authenticate broker domain users. That means that if you want to authenticate your broker domain users against a Windows security registry (like an ActiveDirectory windows domain) then you should run the configmgr on windows.
You should never consider where the broker is placed when considering where to place the configmgr.
You can also consider running one configmgr for each broker, and manage the security of each broker entirely separately from the others.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Dec 25, 2006 1:04 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Would it work for the Config Mgr and local QM to be running on Windows and the Broker running on AIX and be client connected to the same Windows QM? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 25, 2006 2:43 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No.
Broker also has to be server-connected to a local queue manager.
It works just fine to run configmgr on Windows and Broker on AIX.
You just need two queue managers.
This is basic configuration of the product. You should really get training on Broker, it's not terribly easy to learn on your own.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 25, 2006 7:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And be aware that in V6 the configmgr can run on almost any platform the broker can run on...
The toolkit is limited to Linux and Windows...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Dec 25, 2006 7:31 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| I am aware of the platform stuff. My intention for the test was to run the Toolkit, Config Mgr, and Broker all on the same Windows XP box. Ultimately, in upper environments I would be running the Toolkit and Config Mgr on Windowx XP and the Broker on AIX or Solaris. That is why I wanted to configure the test environment with a QM for the Config Mgr and another QM for the Broker, because in upper environments the Config Mgr on Windows would need its own QM for admin, and the Broker on AIX would need its own QM on AIX for admin. What I don't know is if the sender/receiver channels and remote queue definitions are handled automatically by the mqsicreate tools. |
|
| Back to top |
|
|
| jeevan |
| Posted: Mon Dec 25, 2006 9:44 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
jefflowrey Wrote:
| Quote: |
You should never consider where the broker is placed when considering where to place the configmgr.
You can also consider running one configmgr for each broker, and manage the security of each broker entirely separately from the others
|
From the above, I understood:
We should not put broker and configuration manager in the same box
There should be one config manager for one broker.
I do not know how many flows ( application ) can be run in a broker optiomally. If that number is not big, and if a company wants to run many applications on broker, would not it require a lot of machines for running broker and config manager? I am just curious.
My understanding was, we can run (practically run) many brokers in a configuration manager ( broker domain)
[/quote] |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Dec 26, 2006 4:51 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
My understanding is somewhat different than yours but I don't know if it is correct.
I think that:
The Toolkit must be run on Windows or Linux.
The Configuration Manager and its admin Queue Manager can be run anywhere (the same box as the toolkit or not)(Windows, Linux, AIX,Solaris).
The brokers with their admin Queue Managers can be run anywhere (including the Windows box the Toolkit runs on)(Windows, Linux, AIX, Solaris). |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Dec 26, 2006 5:36 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
You can run many brokers in one domain. I would not run more than one broker on a machine or LPAR. You can have many execution groups (EG) and many flows on one broker. The limits are really machine dependant.
Every EG is a separate process and every flow (instance) is a separate thread.
Like Jeff said, put your CM where you want to authorize the developers and administrators. If you want to authorize with Active Directory, then windows for the CM is your easiest choice.
And yes, you need channels between your CM and brokers when they do not share the same QMGR (on the same machine or not).
There is a Redbook on Broker Basics available for free.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 26, 2006 7:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| ivanachukapawn wrote: |
| My understanding is somewhat different than yours but I don't know if it is correct. |
Yours is correct.
It's perfectly fine to run a configmgr on the same machine as a broker. It uses minimal resources when it's not doing any work, and doesn't even have to be running most of the time.
It's perfectly fine to have many brokers connected to one confimgr, and that's how I would normally do it.
It's perfectly fine to have one configmgr for each broker, and that's how many people do it. I personally think this makes everything more complicated, but there are good reasons for doing it this way too.
The configmgr defines a security domain - who can do what to which things. The brokers that should be part of that security domain should be registered to that configmgr.
There isn't a specific number of flows that can run well in one execution group. There isn't a specific number of execution groups that can run well in one broker. There isn't a specific number of brokers that can run well on one machine.
There isn't a standard practice for how many flows to put into one EG, or how many EGs to put into one broker. It's generally not *necessary* to put more than one broker on each machine - although there may be administrative/security reasons for doing so.
Particularly for a production environment, you should plan for the deployment configuration inside each broker to be TUNED iteratively. That is, you should make a good guess for what's reasonable to start, collect metrics, analyze the metrics, and then figure out how to reconfigure (if necessary) for better performance.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
