| Author |
Message
|
| raj429 |
 Posted: Thu Oct 07, 2010 6:12 pm Post subject: withoout showing in ipprocs, can an application pull anymsgs |
 |
|
Acolyte
Joined: 04 Jul 2009
Posts: 53
|
HI,
I was in a testing with application team, wanted to check if the below scenario is possible or any one came across.
There is a local queue, from which Application's WAS instance has to pick up the message from it. When a message comes on it application team is polling it and they pick the response. But I can't see any ipprocs on the queue...is this possible.
For testing, I have get disabled the q and applicatino got 2016 reason code. So they are picking from it for sure...
I have enabled MONQ(LOW) and checked PUTTIME and GETTIME on queue are gettting updated.
withoout showing in ipprocs, can an application pull any messages?Any other way to check it..
I have asked app team couple of questions, but they are like not aware of what & how is it working and I serached for this on this thread but in vain. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Oct 07, 2010 6:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What's faster?
A. The amount of time it takes you to issue the commands twice to get IPROCS.
B. The application opens the queue, grabs the message(s) and closes the queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 07, 2010 6:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The time the application actually has the queue open between
| Code: |
session.createReceiver(Destination); // or with added selector
connection.start();
receiver.receive(waittime); // or receiver.receivenowait();
receiver.close(); |
is the time that the IPProcs would show.
If this time is too short to register you can consume messages from the queue without the ipprocs showing anything...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| raj429 |
| Posted: Thu Oct 07, 2010 6:55 pm Post subject: |
|
|
Acolyte
Joined: 04 Jul 2009
Posts: 53
|
Peter,
I was not sure of option B 100%, that application taking the messages from queue may be faster. CoZ, I tried optiona A, pasting the dis qs command as fast as I can  , but it deceived my eyes..
So, this question cropped in my mind...can it miss ipprocs
Saper,
Thanks, I have to check with my app team that what is the waiting period, Which obviously they dont know or not answering me..
Anyway, now I am clear that..no one can escape from ipprocs..some are faster and some not. right? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 08, 2010 5:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What is your purpose in displaying ipprocs?
If it takes 50ms to open the queue, consume the message and close the queue, you would need to display ipprocs (or queue depth) at precisely the moment when the queue is open - difficult to accomplish, as you've discovered.
_________________
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 |
|
|
| raj429 |
| Posted: Fri Oct 08, 2010 8:50 am Post subject: |
|
|
Acolyte
Joined: 04 Jul 2009
Posts: 53
|
Well to talk about the purpose, I have to talk about actual problem..
Initially when application team said they were not able to get the messages from the response queues(but msgs are on the q), I checked for any MQ errors thrown at app but none.
And I was skeptical whether they are connecting to right queue or not. I have asked the MQ config details from app end but they provided none to us...So, thought of finding it out through ipprocs and yes I realized its not possible always |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 08, 2010 9:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| raj429 wrote: |
| So, thought of finding it out through ipprocs and yes I realized its not possible always |
I think in that scenario your idea of disabling the queue & watching their application blow up is the easiest & most reliable method.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 08, 2010 10:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| not able to get the messages from the response queues |
This kind of statement is not a sufficient to do any meaningful problem-determination.
Not able? Does this mean that the consuming app has not been written yet? Does it mean that there is a power-outage that keeps them from running the consuming application? Or does it mean that the application received a ReasonCode?
When you hear the above kind of symptom from your developers or users, ask them: "How do you know that you not able to get messages?
_________________
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 |
|
|
| raj429 |
| Posted: Fri Oct 08, 2010 10:56 am Post subject: |
|
|
Acolyte
Joined: 04 Jul 2009
Posts: 53
|
Bruce,
*not able* i used here, let me tell the whole problem,
Application is failing to pick up 1 response msg out of 3 or 4. To be specific, 1 response they picked it, 2nd also picked by app and 3 rsp is pending in rsp queue....
1. There is no error in WAS app instance or any thing
2. App dint get mqrc 2033 also, for clearing the doubt increased the waiting period but no use.
3. I have browsed the queue and pasted the msg details and rsp is produced by same application as for previous msgs.
4. now There is 1 pending rsp msg in q, if another successful msg comes in it is picked up by app. So I suggested, by what way are you/app picking msg ie, msgid or corrid or something..
if that is known, then might be tht field in the msg could be problam and can check with the broker rsp app on why is doing that..
Note, This entire setup is in MQ cluster.
my bad is, Application guys dint provide, the logic of picking the msg, the MQ config information and they can't compare the failure msg with success one as succecss one is consumed they say....testing is still going on
App team say, there code is fine and some problem with MQ and I am defying that.
Here I said, application is *not able* to, coz rsp msg is arriving to the destination q and there on its app responsibility to pick from it and its not able to for that msg..reason unknown so far |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 08, 2010 11:36 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The developers need to create the appropriate test/trace nodes in the broker to see what it is doing/not doing.
Developers frequently try to affix blame on MQ. MQ doesn't lose messages.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Oct 08, 2010 11:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| The developers need to create the appropriate test/trace nodes in the broker |
This appears to be a WAS app, no broker involved? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 08, 2010 11:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Oooops.
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Oct 08, 2010 1:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
App team say, there code is fine and some problem with MQ and I am defying that.
Here I said, application is *not able* to, coz rsp msg is arriving to the destination q and there on its app responsibility to pick from it and its not able to for that msg..reason unknown so far |
Well the app code may be fine. However if they did not take into account the transactionality aspect for their request they may be looking for the response without having ever committed the request!
Make sure the app team has also taken into account that if in was the global transaction is enforced unless instructed otherwise regardless of the parms set on session creation (conn.createSession(....,...); )
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Oct 08, 2010 2:55 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| raj429 wrote: |
| App team say, there code is fine and some problem with MQ and I am defying that. |
Start trace, with API options : "strmqtrc -m QMNAME -t api"
Get the app team to recreate their problem.
End trace : "endmqtrc -m QMNAME"
Format the trace with dspmqtrc if this is not Windows.
Send the formatted trace to the app team. Keep a copy. The onus should be on them to prove their app is not at fault.
When messages are not sent or picked up by an application suite, it is probably the application suite's fault. How could it be the administrator's problem to solve? |
|
| Back to top |
|
|
| raj429 |
| Posted: Fri Oct 08, 2010 5:51 pm Post subject: |
|
|
Acolyte
Joined: 04 Jul 2009
Posts: 53
|
Bruce,
Req - rsp setup is betwn WAS-MB. MB rsp msgs should b consumed by WAS app instance.
saper,
Even if they dint comit the global transactions, when its rollbacked msg should be taken of from queue right, but faulted msg is there after couple of next successful msgs also.
I never thought of this, anyhow will shoot it at App team.
mvic,
thanks, I have never done MQ trace so far. I will do some preperation before doing this. any suggestions that I should keep in mind?
Its a UAT env, We have AIX ans Sun os boxes mq' running on. we are running on MQ 6.0.2.X, exact version i can give on monday. |
|
| Back to top |
|
|
|
|
