| Author |
Message
|
| gavon stone |
 Posted: Thu Apr 28, 2005 9:11 am Post subject: backup queues |
 |
|
Novice
Joined: 09 Mar 2005
Posts: 16
|
| Is there a way to create a backup queue with Websphere MQ so that when the main queue is full data is automatically sent to the backup. Also when the main queue is brought back to a certain safe depth then the data is placed onto the main queue with all this being transparent to the user or application program. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Apr 28, 2005 9:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
By misusing the dead letter queue handler and writing code.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Apr 28, 2005 10:01 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| Won't the dead letter queue trick only work for remote messages? If he is putting locally, he should get back the 2053 (queue full) error. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 28, 2005 10:55 am Post subject: Re: backup queues |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| gavon stone wrote: |
| Is there a way to create a backup queue with Websphere MQ so that when the main queue is full data is automatically sent to the backup. |
Where is the backup q?
Where are the messages arrivuing from?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 28, 2005 11:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bower5932 wrote: |
| Won't the dead letter queue trick only work for remote messages? If he is putting locally, he should get back the 2053 (queue full) error. |
Yeah. That part is covered under "writing code"... 
An API exit will handle local queue puts.
But generally, this whole thing is far more trouble than it's worth, and far more effort than it's worth, when the flip side is getting developers to handle their errors properly and managing max queue depths in alignment with business requirements.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 28, 2005 11:25 am Post subject: Re: backup queues |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| gavon stone wrote: |
| Is there a way to create a backup queue with Websphere MQ so that when the main queue is full data is automatically sent to the backup. Also when the main queue is brought back to a certain safe depth then the data is placed onto the main queue with all this being transparent to the user or application program. |
You could but why would you want to ?
Make the queue big enough in the first place and handle the rest as exception situations.
Or load balance in a cluster... or multithread your receiving app....
Enjoy  |
|
| Back to top |
|
|
| malammik |
| Posted: Thu Apr 28, 2005 3:33 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 28, 2005 3:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| malammik wrote: |
| Say ur max depth is 10. Write a trigger with a triggering condition of depth 10. Have the trigger write the data off to another queue manager or another filesystem and send u an alert. |
I would recommend setting your trigger depth at 10, and your max depth at ... 20. Triggering takes some time, and processing takes some time... and the goal here is to prevent the sending application from getting an error when the queue is full.
But I wouldn't recommend doing this at all, so it's really a moot point.
The sending application should shut down when it gets a queue full error. This is very much a sign that something horrible has gone wrong with the entire universe and the application should gracefully quit, rather than spamming the ether with emails and more messages.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| malammik |
| Posted: Thu Apr 28, 2005 3:51 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
I disagree because sending application should not depend on the status of the receiving application - hence asynchronous. Infrastructure must be flexible enough to handle this kind of situation. Here is the real life example.
A retailer Q processes customer orders from call centers and web site at the rate of about 2500 per minute on special night. Should the order entry application be denied access to queue because it is full, it will have enough storage for about 1 hours it will have more storage for another hour but at a very degraded performance.
Now, how the infrastructure handles this is a totally different question. Writing a trigger that empties a queue to an auxilary storage is a hack but it might work for some. Setting ur max queue depths to very high values that will never be reached is safe but sloppy and prevents one from calculating precise amount of storage needed based on:
business requrements
max message lenght for that app
traffic volume, etc.
My best solution is do everything u can not ever be in the situation like that.
_________________
Mikhail Malamud
http://www.netflexity.com
http://groups.google.com/group/qflex |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 28, 2005 4:40 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Malamik -
I agree.
The sending application SHOULD NOT care if the receiving application can't process things as fast as the sending application.
That's why it should shut down if it's gets a queue full error. As I said, it means that, for the sending application, the entire infrastructure has gone ... up. Therefore, it should quit until it can be instructed that E now = MC^2 again.
In the case of your retail situation... this is what transmit queues and channels are for. If the actual queue on the other side fills up, then new messages will go to the DLQ. If the xmit queue fills up... then the MQ Admins aren't getting notified properly that the channel is down, and the universe is therefore broken.
And if a POS system is acting as a direct client to your only Queue Manager - then you need to loosen the purse strings just a <i>wee</i> bit and buy another QM.
Pathological business decisions are no substitute for good architecture.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
