| Author |
Message
|
| javagate |
 Posted: Tue Dec 06, 2005 4:23 am Post subject: What is the longest time you allow a msg to stay on a ql? |
 |
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
What is the longest time you allow a msg to stay on a ql?
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Dec 06, 2005 4:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
As long as it needs to be there, and no longer.
There's no specific time period I would use. But messages that tend to stay on queues for a long time (more than a day) are likely being used by an application that is trying to treat a queue as a database. And MQ queues aren't designed to be used as databases. So I discourage that kind of application behavior.
But, for example, if a developer wants to write a small message consisting of a record id onto a queue, and have it sit there until the end of the month when the whole queue gets cleaned out to generate the monthly report...
Well, I'd consider it. I'd recommend a database or a flatfile instead... but I'd consider it. As long as the record was small.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Tue Dec 06, 2005 5:08 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I would also resist the temptation when building request/reply scenarios to say things like "the requestor will be waiting for 30 seconds, so we'll make it 45 seconds for expiry, just in case". There's no point. If you're going to timeout waiting for a response after 30 secs, then why set the expiry of the message so that it can get processed, 1, 2 or 15 secs after you've given up on a response.
If the server end receives the message, processes it and sends a reply with the remaining expiry interval as the reply expiry, it will take at least your original expiry interval to be returned to you assuming that the server takes no time processing (which is generally reserved for simple echo programs) and transmission takes no time.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| javagate |
| Posted: Tue Dec 06, 2005 5:35 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
When I say long periods of time I am talking weeks and months. ex, duplicate backup messages up to 32k.
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 06, 2005 5:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| javagate wrote: |
| When I say long periods of time I am talking weeks and months. ex, duplicate backup messages up to 32k. |
Are you asking how long a message can sit on a queue? Until it's gotten, as long as it's a persistant message.
But it's all about useage and resource availability.
Are the messages intended to sit there just in case? maybe put them in a file or a database instead, where they can be selectively and easily retrieved as well as stored to archive media in a more portable format.
Do you have the disk space to keep the messages in the queue file?
There's nothing exactly wrong with using a queue as a long term storage unit - except it's not designed for that, and there may be better tools for doing so. It all depends on when and why the messages are ever gotten off the queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Dec 06, 2005 12:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| There's nothing exactly wrong with using a queue as a long term storage unit - except it's not designed for that, and there may be better tools for doing so. It all depends on when and why the messages are ever gotten off the queue. |
SYSTEM.CLUSTER.REPOSITORY.QUEUE
SYSTEM.AUTH.DATA.QUEUE
IBM thinks they are good place to store messages for a long time!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Dec 06, 2005 12:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| scottj2512 wrote: |
| If you're going to timeout waiting for a response after 30 secs, then why set the expiry of the message so that it can get processed, 1, 2 or 15 secs after you've given up on a response. |
Because the orphaned reply messages help indicate that there is a problem. If you see orphaned replies every day from 11 AM till 1 PM, that's useful info.
I hate applications that set Expiry to a very low value. It makes debugging IMPOSSIBLE if messages are blinking away.
I like to setr Expiry to a couple of days or so. If an app's queues can't deal with a couple day's worth of expired messages, then there are bigger issues (i.e. why are there so many late replies?)
Tiny Expiries mask problems.
IMHO
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jsware |
| Posted: Fri Dec 09, 2005 8:00 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| PeterPotkay wrote: |
| Because the orphaned reply messages help indicate that there is a problem. If you see orphaned replies every day from 11 AM till 1 PM, that's useful info. |
I was specifically talking about the request message, but I would argue that the expiry of a response should have the remaining interval from the request.
What you are looking for is addressed by the Report options as documented under Chapter 5 (Handling program errors) in the Application Programming Guide.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 09, 2005 4:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| scottj2512 wrote: |
| PeterPotkay wrote: |
| Because the orphaned reply messages help indicate that there is a problem. If you see orphaned replies every day from 11 AM till 1 PM, that's useful info. |
I was specifically talking about the request message, but I would argue that the expiry of a response should have the remaining interval from the request.
What you are looking for is addressed by the Report options as documented under Chapter 5 (Handling program errors) in the Application Programming Guide. |
Sure but you might not want to trouble the reply to queue with a message that is a report message when you are really looking for the reply message. |
|
| Back to top |
|
|
|
|
