| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Regarding using a same local queue by src and tgt systems |
« View previous topic :: View next topic » |
| Author |
Message
|
| kishi_25 |
 Posted: Thu May 24, 2018 6:39 pm Post subject: Regarding using a same local queue by src and tgt systems |
 |
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
Hi,
We have a requirement where Application A puts message to Queue Q1 and Application B gets message from same queue Q1.
option 1:
using single local queue, which will be used by Application A to put and Application B to get from same queue
Option 2:
use an Alias queue QA1 by Application A with target as local queue Q1. and to use an Alias queue QA2 by Application B with target as local Q2..
I heard that with option 1, there will be logs writing issue at QMGR level and with option 2 is suggested method.
Can some one suggest, will there be any serious issues with option1 or it's an issue only during extreme scenarios? As we already used option1 close to production, going back to option 2 will involve multiple teams testing and time consuming. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu May 24, 2018 9:06 pm Post subject: Re: Regarding using a same local queue by src and tgt system |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kishi_25 wrote: |
Hi,
We have a requirement where Application A puts message to Queue Q1 and Application B gets message from same queue Q1.
option 1:
using single local queue, which will be used by Application A to put and Application B to get from same queue
Option 2:
use an Alias queue QA1 by Application A with target as local queue Q1. and to use an Alias queue QA2 by Application B with target as local Q2..
I heard that with option 1, there will be logs writing issue at QMGR level and with option 2 is suggested method.
Can some one suggest, will there be any serious issues with option1 or it's an issue only during extreme scenarios? As we already used option1 close to production, going back to option 2 will involve multiple teams testing and time consuming. |
Option 2 should read:
use an Alias queue QA1 by Application A with target as local queue Q1. and to use an Alias queue QA2 by Application B with target as local Q1..
Don't know which Q2 you'd bring to the table to get messages from where you never put them in the first place...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 25, 2018 5:45 am Post subject: Re: Regarding using a same local queue by src and tgt system |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| kishi_25 wrote: |
I heard that with option 1, there will be logs writing issue at QMGR level and with option 2 is suggested method. |
I'm not sure exactly what you heard, and from whom.
Log entries are written for MQPUT/MQGET of persistent messages, transactional events and object definitions.
Message persistence is usually set by the app. Three choices: this message is persistent, this message is non-persistent, OR message persistence should be determined by the queue attribute value Persistence-as-defined-at-the-queue.
Using a QAlias vs. a QLocal vs. a QRemote will impact logging ONLY if the app, at MQPUT, specifies that this message should be persistent based on the Persistence-as-defined-at-the-queue.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri May 25, 2018 6:43 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
If the persistence is set as yes on Alias queue and local queues, will there be any issue with option 1?
This came in one of our team discussion. It seems, if We use option 1 - using both the applications to put and get at same time for local queue directly, there might be some contentions at log/transaction level.
This can be better handled by option 2 - As applications A and B will come through Alias queues, there won't be contentions.
I'm not sure how far it's true. so, tried to do some research on google and infocenter, couldn't find any such issues reported.
so thought of taking peoples experience/opinion here. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 25, 2018 7:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Attributes of The first object name MQOPENed will determine things like message persistence.
So, if the app opens a QAlias or QRemote, AND the app specifies persistence-as-queue-def, AND queue attribute specified defpsist(YES), then the msg will be persistent - and will be logged.
Persistent messages invoke logging. Logging imposes a small bit of delay as the logged image is written to the log-file holding disk. Non-persistent messages do not impose logging or logging delay. If your messages have no real value, then make them non-persistent.
What o/s? What MQ version? What hardware? Are you/your apps missing service-level agreements? Why the concern with log contention?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun May 27, 2018 6:03 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| kishi_25 wrote: |
This came in one of our team discussion. It seems, if We use option 1 - using both the applications to put and get at same time for local queue directly, there might be some contentions at log/transaction level.
This can be better handled by option 2 - As applications A and B will come through Alias queues, there won't be contentions.
I'm not sure how far it's true.
|
I think you will find this is not true. The alias is basically a name redirection. All message logging, multi process management, queue handles etc is all done at the local queue level.
Can you provide the source of information brought up in your team discussion?
_________________
Glenn |
|
| 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
|
|
|
|
