| |
|
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
|
| sebastia |
 Posted: Fri May 30, 2008 7:40 am Post subject: Alias queue(s) dont work as I suposed |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi ! I was a great defender of "alias" queues
as a method to separate the application from the administration world.
But I have found 2 functions that Alias queue are not able to provide me
...
Maybe you can tell me the reason for them or how to solve those items...
(a) an alias queue can not be asked its depth.
I have tried first RUNMQSC then DISPLAY QL
and it says the queue does not exist, which is quite true.
And DISPLAY QALIAS(*) CURDEPTH does not display any value,
as the "alias" queue does not have any "own" depth,
neither I am asking for its value, but of the associated "base queue" ...
Second, I tried "MQInq()" API call, but the result is the same,
as you can suppose.
Any solution to know the depth of a queue associated to an Alias q ?
(without using the "real" queue name, of course ... )
(b) I like very much the "mirroring" of a queue, using an API Exit,
as detailed here :
>>> https://www-304.ibm.com/jct09002c/isv/tech/sampmq.html
The code I use is ... mirrorq.c and it works fine ...
if you put messages into the queue listed in the NameList.
If you create an "alias" for it
and use it to write into the same "real" queue,
the API Exit does not get "triggered",
so the message is NOT MIRRORED !
And that is not quite nice, is it ?
And will be glad to hear your opinions !
Sebastian. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri May 30, 2008 8:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
A WMQ fundamental concept:
A QLOCAL is the only type of queue that can host a message. All other queue definition types (QMODEL, QALIAS, QREMOTE) are merely definitions that MUST resolve to a real local queue (QLOCAL). As such, only a QLOCAL has depth.
_________________
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: Fri May 30, 2008 12:33 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Bruce - I do agree with the concept you tell me.
But what about my customer ?
I told him : it is very good you do NOT use the local queue ;
your applications uses an Alias queue,
so we can do .... lots of nice things,
as change from one QL to another withour disruption,
easy and fine permits administration, etc etc
Now they come and say "I cant read my queue depth"
Well - I shall tell them the concept,
but they still want to know if the queue has reached a threshold ...
( )
And it doesn't matter how many concepts I tell them,
if our product does not solve their needs ...
I bet you understand what I mean ...
Thanks ! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 30, 2008 12:43 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
And DISPLAY QALIAS(*) CURDEPTH does not display any value,
as the "alias" queue does not have any "own" depth, neither I am asking for its value, but of the associated "base queue" |
Look at the MQOD (object descriptor) in the WMQ Application Programming Reference. Look at the field ResolvedQName.
This field will contain the name of the real local queue after the qmgr has successfully resolved the queue name that the program opened. Your application could open the queue (alias), then look at the ResolvedQName to discover the real local queue, then MQINQuire on the depth of the real local queue.
And, yes, I do understand what clients want. In this case, you can meet their requirement.
_________________
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: Fri May 30, 2008 12:50 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, I can see you are good in API programming,
and the trick can provide the result.
But it also implies they KNOW it is NOT a real Local queue.
Or "maybe" it is not ...
Because you dont want ALWAYS to open the queue twice, do you ?
Now I have to tell them they shall do it twice ...
I can try !
Thanks for the clue, Bruce.
I shall print that field before going to bed .... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 30, 2008 2:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sebastia wrote: |
Now they come and say "I cant read my queue depth"
|
Then you say "You are not a monitoring program. You are not an MQ Admin. The q depth is not your concern. And if you designed your program to check the q depth and do that many MQGETs, than your program is designed wrong."
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sebastia |
| Posted: Fri May 30, 2008 3:06 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Well, Peter - there are times I have to agree with the customer.
If they dont care about the queue depth,
they shall get a "queue full" return code sometime,
and then wait for the recovery.
If they do some kind on monitoring,
and try to slow down the producer application
when some threshold is reached,
then all can work a bit more smooth ...
It doesn't have to be "go / no go".
Now it can be : go 100%, go 90%, go 40%, go 20%,
which I find very professional.
I think the Alias queue INQ() could give me back
the (target) queue depth ...
A possible solution : I remove MQ_INQ()
and replace it by a "MY_INQ()" ...
I have to thnk about it ..
Thanks ! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 30, 2008 3:17 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
There monitoring/automation tools that can monitor many things, inluding queue depth. Tivoli and other vendors sell them.
There are queue attributes that you can set to create event messages when queue depth gets to a percentage-full or full. You could write an application to watch for these event messages.
Slowing down the message producer so as not to overwhelm the message consumer seems like an odd solution. Perhaps more concurrent consumer programs would work. MQ clustering of the queue where the producer MQPUTs the messages might help distribute the workload.
Perhaps it's time for faster hardware on the consuming platform.
_________________
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 12:32 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Bruce : I have a little problem maybe you can help with.
I am trying to use ResolverQueueName returned by a MQ_Open() call
to connect to that local queue
to display its depth ... but the field is empty !
I did a MQConnect() using a Client library and MQSERVER envir var, RC=0
Did a MQ_Open() to an Alias queue, and RC=0.
I print the OpenDescriptor
and have a good "ObjectName", a nice "ObjectQMgrName"
(I did fill those fields)
but "ResolvedQName" and "ResolvedQMgrName" ARE EMPTY !
Any clue ?
Thanks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jun 01, 2008 6:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzak.doc/mqod.htm
| Quote: |
The remaining fields are ignored if Version is less than MQOD_VERSION_3.
|
| Quote: |
Well, Peter - there are times I have to agree with the customer.
|
And you are paid to tell them when they are wrong!
Your effort should be spent on determining what the max put rate will be and what the max message size will be. Then insure the q is big enough to hold that and there is enough underlying disk space as well. If the apps wants to code something around q depth, they can code something around getting a 2053 MQRC_Q_FULL. Then they can pause for a minute and try again. Of course they will never get that because your monitoring software will alert you when the q is x% full and you will be able to step in and have more consumers fired up and/or have the q depth increased temporarily. You will be able to bump up the q depth because you will have designed your storage requirements on the server to have some extra space waiting for just such an emergency.
Trust us  Don't put q depth logic in an application program. Do programs that write to databases check the size of the database before every insert?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Jun 01, 2008 6:25 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Thanks for the clue, Peter,
but the "version" field is ok,
at least in the Open Descriptor :
==============================
>>> MQCONN. QMN = {INDI}.
>>> MQOPEN. QN = {QAA}.
>>> After Open we have : Version = {3}.
>>> After Open we have : Object Queue Name =
{QAA }.
>>> After Open we have : Object Q Mgr Name =
{INDI }.
>>> After Open we have : Resolved Queue Name =
{ }.
>>> After Open we have : Resolved Q Mgr Name =
{ }.
>>> MQINQ.
--- MQINQ failed with reason code [2068].
==============================
Peter - I almost agree will all thay you,
and I do trust you, the wise men of MQ.
But waiting for RC = Queue Full I think is to wait a bit too much,
if there is anything you (they) can do before.
So, I shall push the "threshold reached event" a bit ..
Thanks. Sebastian. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jun 01, 2008 8:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Are you sure you are programing this correctly?
| Quote: |
2068 (X'0814') MQRC_SELECTOR_NOT_FOR_TYPE
Explanation:
On the MQINQ call, one or more selectors in the Selectors array is not applicable to the type of the queue whose attributes are being inquired.
This reason also occurs when the queue is a cluster queue that resolved to a remote instance of the queue. In this case only a subset of the attributes that are valid for local queues can be inquired. See the usage notes in the description of MQINQ in the WebSphere MQ Application Programming Guide for further details.
The call completes with MQCC_WARNING, with the attribute values for the inapplicable selectors set as follows:
* For integer attributes, the corresponding elements of IntAttrs are set to MQIAV_NOT_APPLICABLE.
* For character attributes, the appropriate parts of the CharAttrs string are set to a character string consisting entirely of asterisks (*).
Completion Code:
MQCC_WARNING
Programmer Response:
Verify that the selector specified is the one that was intended.
If the queue is a cluster queue, specifying one of the MQOO_BROWSE, MQOO_INPUT_*, or MQOO_SET options in addition to MQOO_INQUIRE forces the queue to resolve to the local instance of the queue. However, if there is no local instance of the queue the MQOPEN call fails. |
Are you sure the queue resolved to is even local to the qmgr you are connected to?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Jun 01, 2008 9:02 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, I am quite sure ... the environment and the code is ok ...
... but there is no "resolved" queue - that is the problem.
The queue I have opened with RC=0
is called "QAA" and is an Alias for "QD1" queue,
that is local in the "INDI" queue manager, yes, connected RC=0.
I am asking for 1 attribute ( the code is taken form "amqsinqa.c" )
Select [0] = MQIA_CURRENT_Q_DEPTH ;
=====================
c:\>runmqsc INDI
display QALIAS(QAA)
AMQ8409: Display Queue details.
QUEUE(QAA) TYPE(QALIAS)
ALTDATE(2008-05-30) ALTTIME(11.27.30)
TARGQ(QD1) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DESCR( ) GET(ENABLED)
PUT(ENABLED) SCOPE(QMGR)
=====================
and the connection is a "client one", using
SET MQSERVER=SYSTEM.ADMIN.SVRCONN/tcp/192.168.187.136(1466)
where there is only one queue manager running :
======================
c:\> dspmq
QMNAME(QM1) STATUS(Ended unexpectedly)
QMNAME(INDI) STATUS(Running)
======================
I repeat : the code is copy of "amqsinqa.c"
without the "trigger" stuff ...
just does Open(qmgr), Connect(queue) and Inquiry. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jun 01, 2008 9:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
What we're trying to explain here is that for the typical business application there is seldom, if ever, a requirement to know exactly how many messages are in a queue.
For purposes of discussion; if an application requires 10 messages to comprise a 'business transaction,' then you could use trigger-type DEPTH to trigger the consuming application when the tenth message arrives in the queue.
The typical business application, not knowing if there are any messages in the queue (and not needing to know), does an MQGET with a WAIT. Some possible outcomes:
If there is a message (at least one), then the application will get the first/next message immediately.
If there are no messages in the queue, the program will wait.
If a message arrives, the wait is terminated and the application gets the first/next message.
If there is no message in the queue and the WAITINTERVAL expires, the application will receive ReasonCode 2033 no message available. At this point, the application will re-issue the get with wait, and repeat this until ...
Again, for the typical business application, knowing in advance that there are n messages in the queue doesn't seem to offer any useful information. There are either messages in the queue OR there aren't.
Writing applications to manage the environment where the application executes in counter-productive. Limiting (constraining) the MQPUTting application because the consuming application can't process the messages fast enough, sound like a hardware problem.
We've learned over the decades NOT to write code around hardware issues, because hardware gets replaced all too frequently. In your case, when the hardware gets upgraded, you will once again need to modify the requesting application to meet the new hardware environment.
_________________
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 9:33 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, mr Bruce - I agree on all your points.
But my customer has an application already running
that monitors the queue depth
and pretends to use it from the PRODUCER point of view,
not the "consumer".
Then I come in, teach them some API tricks ( I also know few )
some Administration features, etc etc
and also the "alias" queue usage.
They say "cool - we do like your idea.
We do want to use to disengage (separate ?) applicition queue name
of the adiminstration queue name, because, as you told us,
we can change the "pointer" (the alias queue base queue)
and the application still works fine."
Finaly, that guy that wrote the queue depth monitor comes into the room.
He says : "my code doesn't run anymore ..."
Ok - I can try to explain them why they shall not access
the "real" queue to measure its depth ...
You provide me few very good reasons ... I agree.
But that "MQ_Inq()" shall work without knowing
if the queue is QL or QA.
I shall put this item in my "wish list" ...
... I have seen MQ v7 running, and I think there is no such feature there !
Again - I will push the Events into the game !
And, again, thank you all for your support.
I really appreciate your it and all your opinions. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
