| Author |
Message
|
| atoms |
 Posted: Wed Aug 24, 2005 12:37 am Post subject: queue cycles messages..? |
 |
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
I have a queue set up on a windows machine to receive persistent messages from a AS400 machine. The problem in this case is that messages get processed from the queue but when the depth reaches zero all the approximately 10000 messages are put back on the queue and the process starts all over again. When I browse the messages on the queue I've noticed that some of them have a fairly high backout count (about 80). Also, these messages are dated several weeks back. I assume that these messages do not get commited somehow when they are processed from the queue and that they are put back on the queue only to be processed once again(?) The application that should be processing these messages is running on WebSphere commerce and WebSphere application server.
This has been working for quite some time now with the queue depth beeing zero and I can verify in the application that these messages really arrives. However, suddenly 10000 messages show up on the queue! How come this happens? Are these messages somehow backed out to a log and then they are put back on the queue when the log is full after several weeks?
If anyone could offer me help that that solves this issue I promise you I'll send you a reward of some sort! |
|
| Back to top |
|
 |
| atoms |
| Posted: Wed Aug 24, 2005 1:39 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Ok, so I've found that the number of uncommited messages for the queue manager is coincidentally set to 10000. If these messages are not commited I can see why there is a problem when the number of messages on the queue reaches above 10300 or so...
Just as a temporary solution to buy me some time, is there a problem to raise the value to say 30000? Does this require a restart of the queue manager? Howcome that the application actually seems to process these messages although they are not commited? I mean, if the processing application can't commit these messages from the queue they shouldn't show up in the app either, should they? |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Aug 24, 2005 2:47 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| atoms wrote: |
| is there a problem to raise the value to say 30000? Does this require a restart of the queue manager? |
Yes, use the command "ALTER QMGR MAXUMSGS(30000)". As you can see it is not per-queue, but per-qmgr. I don't remember if it requires a restart, try it and see.
| atoms wrote: |
| Howcome that the application actually seems to process these messages although they are not commited? I mean, if the processing application can't commit these messages from the queue they shouldn't show up in the app either, should they? |
All these questions and more you should simply direct to the processing application; go to the programmers and ask them to view the code. Apparently what happens is that they use SYNCPOINT without ever MQCMIT, but they commit when writing to database, or file, or whatever their output may be.
For example, a pseudo-code such as
| Code: |
set MQGMO=SYNCPOINT
while (forever)
MQGET message;
INSERTDB "message content is" +message;
DBCMIT
end while |
Will write all messages to db and commit them, but after 10000 all messages processed backout to queue by the qm, although still in the DB; Since the application never MQCMITs, it never gets an error code.
The reason your appl had worked in the past is probably that someone has made an irresposible change of code. |
|
| Back to top |
|
|
| atoms |
| Posted: Wed Aug 24, 2005 3:27 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Thanks for your reply!
| Quote: |
| is there a problem to raise the value to say 30000? |
| Quote: |
| Yes, use the command "ALTER QMGR MAXUMSGS(30000)". |
Do you mean "Yes,..." as in "Yes, there is a problem with raising MAXUMSGS!" or what did you mean by "Yes..."?
As for your other suggestions I will try to follow your advice. As a matter of fact I'm the programmer that should know what happens in the code. I don't really know how I ended up in this situation, but I'm currently the only one responsible for this application. All the others, who wrote the app, have left the company! Great! =) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 24, 2005 3:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is somewhat of a problem to increase the maximum uncommitted messages. It will increase system workload, and could affect a number of things. For example, if you increase this, but your q files are not enabled for large file support- you could end up trying to put more messages on the queue than exist. And in addition, messages on the queue that are not committed are still IN the queue file. So this file could get really big.
You could also cause your log files to fill up completely, and this could also end up doing some really bad things.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Wed Aug 24, 2005 3:41 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
| Ok, this sounds just teriffic! So, what can I do? Create a completely new queue for these messages? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 24, 2005 3:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Fix your app as soon as possible...
Increase the max uncommitted messages, but be prepared for some additional issues...
Decrease the batch size on the channels on the qmgr, to decrease the amount of stuff in the logs that is not related to your app...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Wed Aug 24, 2005 3:49 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
| Ok, thanks. I'll try to do that. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Aug 24, 2005 4:38 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Jeff is right on - you'd be better off changing the program to behave properly then changing MAXUMSGS. There is no reason why mq should handle more than 10000 uncommited messages, or even much less in a one-application environment. |
|
| Back to top |
|
|
| atoms |
| Posted: Wed Aug 24, 2005 8:07 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
| In lack of better solutions, and after an agreement with my superiors, I temporarily solved the problem by emptying the queue. So, hopefully I have bought me some time to clear out what is really going wrong. Thanks again for your help guys! |
|
| Back to top |
|
|
|
|
