ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » Temporary Dynamic Queues?

Post new topic  Reply to topic Goto page 1, 2  Next
 Temporary Dynamic Queues? « View previous topic :: View next topic » 
Author Message
friedl.otto
PostPosted: Thu Apr 16, 2009 12:57 am    Post subject: Temporary Dynamic Queues? Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Apr 16, 2009 1:12 am    Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Apr 16, 2009 1:22 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Apr 16, 2009 1:27 am    Post subject: Reply with quote

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
View user's profile Send private message
WMBDEV1
PostPosted: Thu Apr 16, 2009 1:41 am    Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Apr 16, 2009 1:43 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Apr 16, 2009 1:44 am    Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Apr 16, 2009 2:32 am    Post subject: Reply with quote

Centurion

Joined: 06 Jul 2007
Posts: 116

mqjeff wrote:
Security.


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
View user's profile Send private message
mqjeff
PostPosted: Thu Apr 16, 2009 2:46 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

friedl.otto wrote:
mqjeff wrote:
Security.


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
View user's profile Send private message
friedl.otto
PostPosted: Thu Apr 16, 2009 2:52 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Apr 16, 2009 3:21 am    Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Apr 16, 2009 3:27 am    Post subject: Reply with quote

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
View user's profile Send private message
WMBDEV1
PostPosted: Thu Apr 16, 2009 3:36 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Apr 16, 2009 4:27 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Apr 16, 2009 4:32 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ Java / JMS » Temporary Dynamic Queues?
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.