| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Alias queue(s) dont work as I suposed |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Sun Jun 01, 2008 9:38 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Use the DB example I gave to help make your point. Maybe that will make it clearer for them: A program doesn't check table size before writing a row to a DB, and it doesn't check q size (depth) before putting a message.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sun Jun 01, 2008 9:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
I do agree its an odd restriction not to be able to get the underlying q depth via an Alias q. Add it to the wish list thread, sebastia!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jun 01, 2008 9:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
I understand. The programmer wrote code in such a way that you can not change the type of queue that the application opens. This violates one of the fundamental features of WMQ, namely: queue independence.
Queueindependence means that the type of queue need not be known by the programmer. (The exception being a QModel.) An MQOPEN, when successful, resloves to a real local queue (QLocal).
Your programmers choice of hard-coding the local queue name makes future administration (like moving the application, or having multiple security rules based on multiple aliases pointing to the same local queue) nearly impossible. It seems that the programmer has effectively set administrative policy for you.
I would suggest escalating this to management so that the program gets written correctly, and no future programs use this technique.
_________________
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 |
|
|
| sebastia |
| Posted: Sun Jun 01, 2008 10:56 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
DB sample - nice and educative !
Wish List - I will write it down !
Easy admin - I will try the event msg and the threshold.
Thanks to all. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Sun Jun 08, 2008 12:04 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Just a couple of thoughts on the subject of depth for alias queues
1) What if the alias points to a remote queue name?
2) What if several alias queues point to the same 'base' queue? How do you determine which messages came from which alias queue? Or do you just want the depth for the base queue regardless?
Personally I don't like applications checking a queues depth, mainly becaise the queue depth isn't 100% reliable. I also disagree with applications that try and perform their own monitoring too, mainly because that isn't usually the business function of the application. Monitoring logic (in my humble opinion) should be distinct and seperate from business logic. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jun 08, 2008 4:09 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
3) What if some of the messages in the real local queue are in units of work that have not comitted yet?
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
