On 17/01/2008, melu <[EMAIL PROTECTED]> wrote: > > > James.Strachan wrote: > > > > Its kinda done like that - the JMS consumer inside Camel consumes the > > message as usual, adding the sleep - but then using JMS > > acknowledgements or declarative transactions to consume the message > > after its been sent on. i.e. its reliable. > > > > OK, thanks for explanation. > > But please tell me if you mean that it is using Thread.seep() of Java? I > have many messages per hour (about 100 000) and I need some mechanism to > delay them about 5 minutes. If it is using normal sleep than it is not good > solution for my problem because a lot of memory will be consumed (becasue > many threads will be in sleep state). Am I right?
If all messages are being delayed by the same amount, then its the message broker that will be buffering them up. If you are using ActiveMQ then due to the slow consumers (as they are 5 minutes behind the producers) it will stream to disk. i.e. a delayer will consume a single message, then sleep until the message has been delayed enough, then send it & commit the transaction. So its only gonna process one message at once - its not gonna get 100,000 messages in RAM or anything. With JMS consumers if you are using ActiveMQ you should always be a little careful about the prefetch size - as that does use up RAM - but thats a general JMS thing... http://activemq.apache.org/what-is-the-prefetch-limit-for.html So in summary - delaying delivery of messages is a problem the message broker has to deal with - you're client is just a regular JMS consumer & won't run out of RAM -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
