| Author |
Message
|
| James_O_K |
 Posted: Thu Jul 13, 2006 7:07 am Post subject: How to get newest or oldest message off a queue |
 |
|
Apprentice
Joined: 09 Mar 2006
Posts: 39
Location: UK
|
Hello all,
Been looking at how to get the newest and oldest messages from a queue. I was hoping there would be something in the Get Message Options, but alas thats not the case. Has anyone done anything like this? And if so, can you shed some light?
Thanks
James. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jul 13, 2006 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The oldest is easy. Set the delivery to FIFO and the message you receive from a standard get will be the one that's been there the longest. In a properly designed system where messages don't hang around in queues, it will also be the newest! 
As has been pointed out many times in this forum, a queue is not a database and should be used for storage. If you've got a number of messages and you're trying to find these 2, the only way IMHO is to browse through them one at a time and keep a note of dates & times. There's no inbuilt way of doing it because MQ is not a database doesn't expect to be holding this stuff.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Thu Jul 13, 2006 7:24 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| Vitor wrote: |
| the only way IMHO is to browse through them one at a time and keep a note of dates & times. There's no inbuilt way of doing it because MQ is not a database doesn't expect to be holding this stuff. |
That's not only a IMHO Vitor, this is a fact. No easy way to get the newest.
You will need to browse them all and will have to work with GregorianCalendar (very ugly thing IMHO). |
|
| Back to top |
|
|
| James_O_K |
| Posted: Thu Jul 13, 2006 7:24 am Post subject: |
|
|
Apprentice
Joined: 09 Mar 2006
Posts: 39
Location: UK
|
| Vitor wrote: |
The oldest is easy. Set the delivery to FIFO and the message you receive from a standard get will be the one that's been there the longest. In a properly designed system where messages don't hang around in queues, it will also be the newest!
As has been pointed out many times in this forum, a queue is not a database and should be used for storage. If you've got a number of messages and you're trying to find these 2, the only way IMHO is to browse through them one at a time and keep a note of dates & times. There's no inbuilt way of doing it because MQ is not a database doesn't expect to be holding this stuff. |
Yes, see what youre saying about it not being DB. I am actually looking at a way of dealing with volumes that are too high for the program dealing with the messages. My thoughts being that if the remote site goes down and messages back up, there will be too many to process and the remote site will receive many timeouts even though their message may have been processed. My thinking in this case was to get the newest messages using a controller thread and send back an error response straight away to reduce volumes. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 13, 2006 7:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastianhirt wrote: |
That's not only a IMHO Vitor, this is a fact. No easy way to get the newest.
|
Indeed but given this recent discussion (http://www.mqseries.net/phpBB2/viewtopic.php?t=30614) and the fact that this was posted in the Java / JMS forum I felt qualification was wise.
Java / JMS is not my thing. There might have been some kind of bizarre Java-ish selection method thing. Unlikely, but caution seemed indicated. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 13, 2006 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| James_O_K wrote: |
| Yes, see what youre saying about it not being DB. I am actually looking at a way of dealing with volumes that are too high for the program dealing with the messages. My thoughts being that if the remote site goes down and messages back up, there will be too many to process and the remote site will receive many timeouts even though their message may have been processed. My thinking in this case was to get the newest messages using a controller thread and send back an error response straight away to reduce volumes. |
How can there be "too many to process" whilst at the same time "will recieve many timeouts even though their messages may have been processed"?? 
Either a) the message got processed in the time allowed and the response produced or b) it didn't. If it's a question of round trip time you either need to be thinking in terms of message expiry (to prevent timed out messages - i.e. old ones - being presented and allowing the new ones through) or depth montoring to spin up more instances of the application so they can get processed.
The hint may be in the underlining....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| James_O_K |
| Posted: Thu Jul 13, 2006 8:45 am Post subject: |
|
|
Apprentice
Joined: 09 Mar 2006
Posts: 39
Location: UK
|
| Vitor wrote: |
| James_O_K wrote: |
| Yes, see what youre saying about it not being DB. I am actually looking at a way of dealing with volumes that are too high for the program dealing with the messages. My thoughts being that if the remote site goes down and messages back up, there will be too many to process and the remote site will receive many timeouts even though their message may have been processed. My thinking in this case was to get the newest messages using a controller thread and send back an error response straight away to reduce volumes. |
How can there be "too many to process" whilst at the same time "will recieve many timeouts even though their messages may have been processed"??
Either a) the message got processed in the time allowed and the response produced or b) it didn't. If it's a question of round trip time you either need to be thinking in terms of message expiry (to prevent timed out messages - i.e. old ones - being presented and allowing the new ones through) or depth montoring to spin up more instances of the application so they can get processed.
The hint may be in the underlining.... |
OK, the way it works is this. The remote system sends a message to us real time, we process it against the backend and reply. The remote system has a timeout of 30 seconds set. As the volumes increase, obviously the threads at our end are working harder (and we only have a limited number because every thread needs a user ID/password). So if the messages stack up, we do process them all at our end once they have been picked up from local queue, but it may not be within the 30 secs on remote system so they dont get a reply. Ideally we would get more threads running, but this isnt possible due to limit on user ids available. |
|
| Back to top |
|
|
| xxx |
| Posted: Thu Jul 13, 2006 9:37 am Post subject: |
|
|
Centurion
Joined: 13 Oct 2003
Posts: 137
|
The remote system sends a message to us real time, we process it against the backend and reply. The remote system has a timeout of 30 seconds set
You have to set the message expiry from the sending system to 30 sec, as that is the Max time the Putting application can Wait !
Even if the message was processed after 30 sec their will be no use ! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 13, 2006 2:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The other possibility is to deal with persistent messages in a Fire and Forget mode.
If your app can guarantee processing of the messages it receives including resolving the "poison" message scenario your putting app might be satisfied by just saying message on its way.
After all that's why you have guaranteed delivery right ?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| James_O_K |
| Posted: Fri Jul 14, 2006 12:34 am Post subject: |
|
|
Apprentice
Joined: 09 Mar 2006
Posts: 39
Location: UK
|
| fjb_saper wrote: |
The other possibility is to deal with persistent messages in a Fire and Forget mode.
If your app can guarantee processing of the messages it receives including resolving the "poison" message scenario your putting app might be satisfied by just saying message on its way.
After all that's why you have guaranteed delivery right ?
Enjoy |
Indeed youre right. The way the putting app has been designed pretty much throws the whole guaranteed delivery ethos out of the window. The fact is that at our end, we can quite easily process all the messages and send a reply, but it aint necessarily going to be within their 30 secs. I fear they arent going to change anything, so back to the drawing board for me. Cheers for your suggestions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 14, 2006 12:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| James_O_K wrote: |
| it aint necessarily going to be within their 30 secs. |
So ExpiryMan Returns....... 
(I'm a film buff - sorry )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| James_O_K |
| Posted: Fri Jul 14, 2006 12:39 am Post subject: |
|
|
Apprentice
Joined: 09 Mar 2006
Posts: 39
Location: UK
|
| Vitor wrote: |
| James_O_K wrote: |
| it aint necessarily going to be within their 30 secs. |
So ExpiryMan Returns.......
(I'm a film buff - sorry ) |
I'm lost, put ExpiryMan into google and get "experian" which is some credit reference agency. A film about a credit reference agency doesnt sound like fun... |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 14, 2006 12:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
ExpiryMan Returns - SuperMan Returns - big premier, next big film? Attempting a link with the likely use of expiry to resolve your issue?
Would have been amusing if it had worked but it didn't and it wasn't. Apologies and if you need me I'll be in the corner meditating on the inappropriate use of humour in a technical forum.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| James_O_K |
| Posted: Fri Jul 14, 2006 12:46 am Post subject: |
|
|
Apprentice
Joined: 09 Mar 2006
Posts: 39
Location: UK
|
| Haha Vitor, I shall take rest in the other corner, trying to understand more jokes... |
|
| Back to top |
|
|
|
|
