| Author |
Message
|
| aahmad8 |
 Posted: Mon Apr 09, 2007 11:19 pm Post subject: Sharing channel for multiple queues |
 |
|
Apprentice
Joined: 12 Sep 2005
Posts: 27
Location: Malaysia
|
We have currently a total of approximately 1400 channels running in production in non-cluster environment.
1. What's the best practice to use shared channels (multiple queues using a channel or few channels) vs. one on one (one queue one channel)? Taking into consideration pro and cons if I were to opt using shared channel.
2. We're setting linear logging with the following parfameters in Windows environment as a default.
LogFilePages: (x 4KB) 2560
LogPrimaryFiles: 3
LogSecondaryFiles: 2
Under normal curcumtances we never hit log full but it happen once in a while.
When it happens, restarting the Queue Manager seems failed. Then tried to increase the number of Primary Log File and Secondary File but that also doesn't help. The only way is recreating the objects.
Q1: Is there a way to recover whatever persistant messages?
Q2: Why increasing Primary Log File and Secondary File do not work as mentioned in the Windows manual?
Q3: Can't we set something like threshold before it reaches the maximum size of the logs although it does not happen rarely?. We suspect application did not pick up the message until the logs flooded with huge messages.
Akbar Ahmad
MQ Administrator |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Mon Apr 09, 2007 11:48 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
To "share" channels just use the same XMITQ name in your remotequeue definition. so multiple queues wil be routed by one channel that serves this XMITQ.
You have to make sure e.g. about data conversion, max msg length and so on to cover the need of all queues.
in most cases it is not a good advice to use a 1:1 queue to channel setup.
regarding your log files: increasing the number of logs (before you hit the error, queuemanager restart required) should work. if not, you should check how your application is working or if this is a different error.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| aahmad8 |
| Posted: Tue Apr 10, 2007 2:04 am Post subject: |
|
|
Apprentice
Joined: 12 Sep 2005
Posts: 27
Location: Malaysia
|
A: In most cases it is not a good advice to use a 1:1 queue to channel setup.
Q: I was asked to create channel coresponding to number of qalias but at the same I'm trying to reduce the number of channel to be used for an existing application enhancment unless it's a new project. Below are some info to help you answer my question:
Message Length: approximately 4000 chrs
Daily Messages: 60,000 msgs
Application insist to have separate channel against my intenstion to reduce no. of channels. Reason given was "message load". Is that justifiable? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 10, 2007 3:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is the job of the MQ Administrator to design and manage the MQ network. It is not the job of the application team, and it is not proper to design the MQ network around applications.
Unless your MQ network is already extremely heavily burdened, running on slow and small machines, 60,000 messages more a day will not cause a significant impact on performance of the channel. 60,000 messages ALL AT ONCE might.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Apr 10, 2007 1:24 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
I would not make separate channels to "handle a load" of 60,000/messages per day. Even if they all flood at once, it would be a pretty darn efficient set of applications that could pick them up more quickly than MQ could deliver them. The increased overhead and administration of 1:1 channels:queues will not be justified.
I do, however, sometimes use multiple channels. One reason might be if I want to separate synchronous and asynchronous traffic (usually relative to online/realtime transactions vs. batch transactions).
Another reason I might use separate channels is to isolate traffic for a badly designed/behaving application that doesn't pick up its messages timely, allowing destination queues to fill up. Now I KNOW I shouldn't design MQ to compensate for bad applications, but if I can't get the application to be fixed, sometimes it's the only way to get any sleep. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 10, 2007 11:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
My 2 cents:
I only use separate channels where there is a physical difference in connection, i.e. a box with more than one network card and hence more than one physical route to the machine. Typically (to pick up the point made by SAFraser) these would be used to segrigate traffic. Often one is connected to a bit of CAT 5, the other to some fast fibre and so you put real time across one and batch across another.
That's certainly as close as I get to designing MQ to match application needs. I'd have a negative reaction, despite my newly fluffy outlook, if I was told the design needed multiple channels "because of application considerations".
Also - 60,000 4k messages is not a lot of data for an average network. Especially if it's evenly distributed or in 2 or more peaks.
My personal view, other opinions may be equally valid, etc, etc. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Apr 11, 2007 1:47 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
It could also make sense, to create one channel for SSL encryption and another one, without SSL.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 11, 2007 2:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| HubertKleinmanns wrote: |
| It could also make sense, to create one channel for SSL encryption and another one, without SSL. |
Good point. Not considered that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Apr 11, 2007 5:36 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
Prior to using SSL we had separate SVRCONN channels for each application to use. Each channel had its own MCAUSER so we could control authorizations to the queues.
With SSL we define one SVRCONN per queue manager. We have an exit that derives the MCAUSER from the digital certificate and queue authorizations are set based on that. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 11, 2007 1:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bbburson wrote: |
Prior to using SSL we had separate SVRCONN channels for each application to use. Each channel had its own MCAUSER so we could control authorizations to the queues.
With SSL we define one SVRCONN per queue manager. We have an exit that derives the MCAUSER from the digital certificate and queue authorizations are set based on that. |
I still like the idea of one channel per application. In case of trouble you can always shut down the specific channel without causing pain to any other application, especially if you hit a machine automatic reconnect.
Try and do that with a single channel... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 11, 2007 1:56 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In v6 you can kill an individual CONNECTION from some given application.
So it's not as necessary to have separate SVRCONNs. It does make it easier to kill *all* connections, though. Particularly as a means of preventing the app from establishing MORE connections.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Apr 11, 2007 10:23 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
Using separate channels for each application may make sense for MQI channels (SVRCONN, CLNTCONN) - but not separate channels for each queue.
Using separate channels for each application does not make sense for message channels, because these connect QMgrs and not applications!
Akbar Ahmad,
regarding your questions:
- Q2 (log files increasing): Did you restart the QMgr after increasing the number of logs? A QMgr restart is required.
- Q3 (threshold setting): No, there is no threshold, which you can check. The logs must be at least as big as the biggest expected unit of work UOW). This is neccessary, to be sure, that any UOW is able to be processed.
Still the maximum log size may be reached because of two or more UOWs, which come at the same time. This normally is not a big problem. MQ will backout one or more of them, and then process the residual UOWs. Then the backed out UOWs can be successfully be processed.
So if you see transaction rolled back message "sometimes" (let's say, once a month or less), this is no problem. If you get this message more often (let's say, once a week or once a day or more), you should increase the number of log files - and restart the QMgr afterwards.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
