ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Creating a delaty before processing the message

Post new topic  Reply to topic
 Creating a delaty before processing the message « View previous topic :: View next topic » 
Author Message
WMBEAI
PostPosted: Mon Jun 01, 2009 3:21 am    Post subject: Creating a delaty before processing the message Reply with quote

Acolyte

Joined: 02 Mar 2009
Posts: 66

I have a requirement - The message should be taking from the a particular queue and create a delay for 60 seconds and send to another queue.

My Design:A TimerNotificationNode polls every second which is connected to a MQGet Node picks the message and i have a Java Compute node which creates a delay for 60 seconds and send to o/p.

The Problem here is suppose in my MQGET node i have 1000 messages ,it will reach my destination after 6000 min which is nto acceptable.

Can anyone suggest a good design.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Jun 01, 2009 3:43 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

I refer you to this discussion.

WMBEAI wrote:
Can anyone suggest a good design


It's a bad requirement, so a bad design will be appropraite....

My advice, as I intimated on the other thread, is to push back on whoever's giving the requirement. Find out why they need this delay, then analyse it to see if they really need this delay.

A war story to illustrate my point - I was once told to produce a broker flow that ensured that no more than 10 messages were delivered to a queue in any 10 second period. When I asked about this odd requirement, I was told to just code it as it was a non-negociable application requirement.

3 trout later I discovered the receiving app had 10 threads, took a little under a second to process a message, and wanted the delivered throttled "to ensure a message isn't lost because all the threads are busy when it arrives". It was apparently a well known fact that if a message was left sitting on a queue, the data pixies would steal it....

Ask why.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Jun 01, 2009 3:48 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Vitor wrote:
3 trouts later I discovered the receiving app had 10 threads, took a little under a second to process a message, and wanted the delivered throttled "to ensure a message isn't lost because all the threads are busy when it arrives". It was apparently a well known fact that if a message was left sitting on a queue, the data pixies would steal it....


And it only took you 3 trouts to find that out?

Are you sure the pixies weren't labeled message expiry?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Mon Jun 01, 2009 4:00 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

fjb_saper wrote:
And it only took you 3 trouts to find that out?


Let's just say my reputation preceeded me. Once expressed by a manager who said "When <Vitor's real name> asks 'Are you stupid or just crazy?', accept that you're probably one or the other and deal with it"

fjb_saper wrote:
Are you sure the pixies weren't labeled message expiry?


Oh no, not only in this specific example where the messages both persistent and non-expiring, the assertion was in general that if there wasn't an application actually "listening" on the queue, the message would be lost immediately.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Jun 01, 2009 4:10 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Vitor wrote:
Oh no, not only in this specific example where the messages both persistent and non-expiring, the assertion was in general that if there wasn't an application actually "listening" on the queue, the message would be lost immediately.

Must have been some genius coming up with that assertion. Of course it was entirely beneath him to check its veracity...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Mon Jun 01, 2009 4:53 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

I'm confused. Do you want to delay all messages by a total of 60 seconds? Or delay each message by 60 seconds individually?

Neither requirement makes a lot of sense, but they are still very different requirements with very different solutions. The first requires get-disabling a queue or stopping a message flow. The second could be solved the way you suggested, but it'd be better to use TimeoutControl and push the whole message into the Timeout stream so it comes back out of TimeoutNotification.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Jun 01, 2009 5:39 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

fjb_saper wrote:
Vitor wrote:
Oh no, not only in this specific example where the messages both persistent and non-expiring, the assertion was in general that if there wasn't an application actually "listening" on the queue, the message would be lost immediately.

Must have been some genius coming up with that assertion. Of course it was entirely beneath him to check its veracity...


One of the greatest thinkers of our age. I particually liked his point:

Quote:
Well of course it's lost; where's it going to go? It's not like the queue's going to back it up on the disc if it's not processed!


You really couldn't make this stuff up.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Jun 01, 2009 5:41 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqjeff wrote:
Neither requirement makes a lot of sense, but they are still very different requirements with very different solutions.




You really need to clarify what exactly you're being asked to do, then match that up with what they actually need to happen.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
WMBEAI
PostPosted: Mon Jun 01, 2009 10:52 pm    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2009
Posts: 66

Delay each and every message by 60 seconds.
i know it is not a good design but we want to implement in the one of the server as the Destination system goes dowm when huge amount of messgaes come at the same time..
In real time it will not happen..Just to have things working for now .
Back to top
View user's profile Send private message
AkankshA
PostPosted: Mon Jun 01, 2009 11:17 pm    Post subject: Reply with quote

Grand Master

Joined: 12 Jan 2006
Posts: 1494
Location: Singapore

How are you introducing delay in java compute node ???

Are you using Sleep method....

why dont you use MQGET node with wait interval set to 60 seconds listening on an empty queue for message.... this ll gv u 60 sec delay which u desire
_________________
Cheers
Back to top
View user's profile Send private message Visit poster's website
gs
PostPosted: Mon Jun 01, 2009 11:30 pm    Post subject: Reply with quote

Master

Joined: 31 May 2007
Posts: 254
Location: Sweden

WMBEAI wrote:
Delay each and every message by 60 seconds.
i know it is not a good design but we want to implement in the one of the server as the Destination system goes dowm when huge amount of messgaes come at the same time...


You want to put a delay on each message to decrease the load on the receiving system? However, you don't want it to take 6000 minutes then why not shorten your delay to whatever the receiving system can process?
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Jun 01, 2009 11:31 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

WMBEAI wrote:
Delay each and every message by 60 seconds.
i know it is not a good design but we want to implement in the one of the server as the Destination system goes dowm when huge amount of messgaes come at the same time..
In real time it will not happen..Just to have things working for now .


Sounds like trigger every?

Messages should be pulled from the queue (MQGET) by whatever wants to process them and it should do so in a way that is sustainable. Introduce a delay between MQGETs if you must, but don't delay message delivery.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Jun 02, 2009 2:13 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

zpat wrote:
WMBEAI wrote:
Delay each and every message by 60 seconds.
i know it is not a good design but we want to implement in the one of the server as the Destination system goes dowm when huge amount of messgaes come at the same time..
In real time it will not happen..Just to have things working for now .


Sounds like trigger every?

Messages should be pulled from the queue (MQGET) by whatever wants to process them and it should do so in a way that is sustainable. Introduce a delay between MQGETs if you must, but don't delay message delivery.

If this a trigger every problem in CICS you need TCLASS the transaction to limit the number of concurrent transactions allowed in the system.

If it is a trigger every problem in a distributed system you need to configure your app to exit after a certain max resource utilization is hit.

In no way should you implement a delay.

Happy programming!
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Creating a delaty before processing the message
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.