| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Blocking Failure |
« View previous topic :: View next topic » |
| Author |
Message
|
| klamerus |
 Posted: Fri Apr 28, 2006 5:10 pm Post subject: Blocking Failure |
 |
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
What happens if two applications attempt to write to the same queue at roughly the same time?
We have 8 or so different applications all attempting to put status messages on a status queue. We understand that there is some logic in these to put their status messages on an error queue in this application if they are unable to do this.
We've started seeing this happen, but the status queue is fine (not full or anything) and > 99% of the time the messages get there, but we find that sometimes they don't.
So, the question is what happens if one application has connected to a queue and is the process of putting a message on it and another attempts to connect or do a put?
Will the requests queue or will the second fail. It may be that we need the developers to put some sort of retry into their code. That's just our guess as to what's happening though.
Thoughts? Can two applications interfere with each other in this way? |
|
| Back to top |
|
 |
| EddieA |
| Posted: Fri Apr 28, 2006 7:30 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| What happens if two applications attempt to write to the same queue at roughly the same time? |
As long as the application has been able to OPEN the Q, to eliminate any non-shared queue problems, it will work.
| Quote: |
| but we find that sometimes they don't. |
What happens. Do you get an error.
| Quote: |
| Will the requests queue or will the second fail |
The messages will be written.
| Quote: |
| Can two applications interfere with each other in this way? |
If they are discreet applications, no. If they are badly written threads of the same application, yes.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| klamerus |
| Posted: Fri Apr 28, 2006 9:12 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
What we have are several applications.
This is some code we inherited (poorly documented, poorly commented, poorly everything), so we're struggling to figure it out.
Anyway, these are separate applicaitons (not threads). They do a connect, open, put, and close and disconnect. There's no retry logic in them, but there is code to write the message to a different queue in the event of a failure.
What we're seeing is messages showing up on this other queue, and we're trying to figure out why they're there. One thought we had (since there is no retry) is that we're getting several applications trying to write at the same time (or close enough) that one is failing.
The messages can be large (can be up to a MB at times, but usually not).
It would be nice if there were some sort of MQ trace that we could turn on for this that capture all transactions and results (like in Oracle, etc.).
Sadly (as you could expect) the occasions where this could happen are rather rare so we only get maybe a dozen of these in any day (out of 50,000 or more messages). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Apr 29, 2006 5:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| klamerus |
| Posted: Sat Apr 29, 2006 5:36 am Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
| Hmmm. Would you know if this works with MQ 5? We're on 5.3. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Apr 29, 2006 6:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
strmqtrc -t api will work on MQ 5.3. You can then look atthe output and try and find if one of the MQPUTs is failing, and with what reason code. That will be the key to your solution.
But there is no RC for "Another Message being Put right now try later". That is not a problem for MQ. The only things I can think of are:
The 1st q fills up occasionally, causing the app to write to the other q.
-or-
The 1st q's Max Message size is smaller than the 2nd q, and these are big messages going to the 2nd q.
-or-
Review the MQPUT call in the APR manual, and look at all the possible MQPUT bad Return Codes, and see if any of them make sense.
-or-
This poorly writen code never even tries to put to the 1st q, there is no failure of that put, but instead goes straight to that other q for some poorly documented reason.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Apr 29, 2006 6:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
One thing that might help you understand the poorly documented programs is to compare them with the sample programs like amsqput, that have source code supplied.
The sample programs are well written and well commented, so if you can follow the structure of what they are doing, and look at the particular method calls they make at each point, then you can look at the "bad" code and try and find those same method calls. From there, you can start to undertstand the structure of the "bad" programs. So if you can find the MQCONN or MQCONNX call, then you know that that part of the program *should* be during the initialization phase of the program, and the MQDISC should be during the shutdown phase, and etc.
Particularly, if you find MQCONN inside the main loop of the program, where it gets executed often, then you know that this is a BAD program and it's connecting far too often.
Sometimes architecture turns into archaeology. That's why I always pack a whip and a hat in my laptop bag... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| klamerus |
| Posted: Sat Apr 29, 2006 7:19 am Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Sometimes architecture turns into archaeology. That's why I always pack a whip and a hat in my laptop bag...
Too funny  . These guys already think I'm a tyrant.
Anyway, seems like the trace is a best first step.
I shouldn't expect we have any issues with the queues as the status queue is usually nearly empty (or with no more than a dozen messages in it). We're not running out of space or message queue length. We know because we have had occasions where to replace one of the executables or another we let messages "pile up" by stopping that code to replace. We have had cases where the queues have gotten to thousands of messages. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon May 01, 2006 12:30 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| Quote: |
Anyway, these are separate applications (not threads). They do a connect, open, put, and close and disconnect. There's no retry logic in them, but there is code to write the message to a different queue in the event of a failure.
|
If you mean these apps are not checking the return code from the mq calls, then you need to update them to do so. 
It is not realistic with this API to have an application that does not do this. Also, depending on what the failure is, it is ludicrous for an application to continue to do MQ calls once an error has occured.
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| klamerus |
| Posted: Mon May 01, 2006 4:49 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
The code does check return values, but it makes no attempt to retry the requests after any sort of timeout. It simply assumes an error and puts the messages on the error queue.
I have to think that the error (if any) that this runs in to is extremely rate since the code in all the executables combined probably makes 50,000 puts (and gets) in any day. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
