Author |
Message
|
friedl.otto |
Posted: Thu Apr 16, 2009 12:57 am Post subject: Temporary Dynamic Queues? |
|
|
Centurion
Joined: 06 Jul 2007 Posts: 116
|
A few questions:
1. Can they only work using Model Queues.
2. If not (since Model Queues only apply to Local Queue settings), can one create a temporary dynamic REMOTE queue? _________________ Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Apr 16, 2009 1:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
... No you can't create a temporary dynamic remote queue.
You can send to any queue you want, whether it exists or not, by specifying whatever values you want for Object Qmgr and Object Queue name in the MQOPEN call.
You can only GET from QLOCALS, including temporary dynamic queues... A very very typical pattern is for a requester to create a temporary dynamic queue, set that as the ReplyToQ name on the request message, and then consume replies. Saveqmgr does this, for example. |
|
Back to top |
|
 |
friedl.otto |
Posted: Thu Apr 16, 2009 1:22 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007 Posts: 116
|
Just to clarify ...
If I have a multi-threaded Windows application (on QMGR A) which does the following for each thread:
1. Construct a unique temporary dynamic queue name.
2. Construct an MQ message with REPLY_TO_Q set to said name.
3. Put said message on a Static Remote queue.
On the other end (iSeries) a single-threaded RPG application fields the said requests on a Static Local queue.
And you're saying that (if the two queue managers have working bi-directional channel pairs) I need not create a Remote queue on QMGR B? _________________ Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Apr 16, 2009 1:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
friedl.otto wrote: |
Just to clarify ...
If I have a multi-threaded Windows application (on QMGR A) which does the following for each thread:
1. Construct a unique temporary dynamic queue name.
2. Construct an MQ message with REPLY_TO_Q set to said name.
3. Put said message on a Static Remote queue.
On the other end (iSeries) a single-threaded RPG application fields the said requests on a Static Local queue.
And you're saying that (if the two queue managers have working bi-directional channel pairs) I need not create a Remote queue on QMGR B? |
Yes.
MQOPEN does not care if there is a QREMOTE or not. If it can find a QLOCAL that matches the Object Queue name, it uses that. Otherwise, it does name resolution on the Object Queue name and Object Qmgr Name.
Welcome to MQ. |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Thu Apr 16, 2009 1:41 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
friedl.otto wrote: |
And you're saying that (if the two queue managers have working bi-directional channel pairs) I need not create a Remote queue on QMGR B? |
You will need a QMGR alias on B so it can the route the reply back to A but this will be static and a new definition wont be needed for each temporary reply queue. |
|
Back to top |
|
 |
friedl.otto |
Posted: Thu Apr 16, 2009 1:43 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007 Posts: 116
|
*depressed sigh ... feeling like a total noob once again*
Why did/do I ever bother remote queues then!  _________________ Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Apr 16, 2009 1:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
friedl.otto wrote: |
*depressed sigh ... feeling like a total noob once again*
Why did/do I ever bother remote queues then!  |
Security. |
|
Back to top |
|
 |
friedl.otto |
Posted: Thu Apr 16, 2009 2:32 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007 Posts: 116
|
Which would have been my next question ...
... how does 'mqauth' work for this 'anonymous' put? I'm guessing the
user credentials will not be conveyed over the channel? _________________ Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Apr 16, 2009 2:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
friedl.otto wrote: |
Which would have been my next question ...
... how does 'mqauth' work for this 'anonymous' put? I'm guessing the
user credentials will not be conveyed over the channel? |
They never are. Even with a qremote. |
|
Back to top |
|
 |
friedl.otto |
Posted: Thu Apr 16, 2009 2:52 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007 Posts: 116
|
mqjeff wrote: |
They never are. Even with a qremote. |
Obviously, since the mqauths would surely be set on the QREMOTE, right? _________________ Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Apr 16, 2009 3:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
friedl.otto wrote: |
mqjeff wrote: |
They never are. Even with a qremote. |
Obviously, since the mqauths would surely be set on the QREMOTE, right? |
Correct. So without the QREMOTE, then it will either be a qmgr alias or the xmitq that is authorized against. |
|
Back to top |
|
 |
friedl.otto |
Posted: Thu Apr 16, 2009 3:27 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007 Posts: 116
|
mqjeff wrote: |
Correct. So without the QREMOTE, then it will either be a qmgr alias or the xmitq that is authorized against. |
In the XMIT case that would yield some fairly course grained auth.
I'm still feeling a little dumb around the ALIAS story. Is the alias
necessary (does it serve any purpose), or is specifiying the QMGR and
remote QLOCAL in the MQOPEN sufficient. _________________ Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Thu Apr 16, 2009 3:36 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
friedl.otto wrote: |
Is the alias
necessary |
Yes, it wont work without it |
|
Back to top |
|
 |
Vitor |
Posted: Thu Apr 16, 2009 4:27 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
WMBDEV1 wrote: |
friedl.otto wrote: |
Is the alias
necessary |
Yes, it wont work without it |
Yes it will so work if you've followed best practice and the xmitq name is the queue manager name.
You only need an alias if:
- you use a different naming convention for xmitqs
- you're doing a multi-hop
- you're adding security. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Apr 16, 2009 4:32 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
WMBDEV1 wrote: |
You will need a QMGR alias on B so it can the route the reply back to A but this will be static and a new definition wont be needed for each temporary reply queue. |
Just to underline the point - you do not need a qmgr alias in all situations.
In the situation this long-time noob (and semaphore destroyer) finds himself in with 2 bi-directionally connected queue managers, provided the xmitq on B is called A the messages will route themselves just fine.
Security is an issue, but the odds of a hacker being able to locate a temp dym queue name fast enough to send a spurious response are reasuringly small. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|