Interesting choice in JMS 2 to add a delivery delay based in milliseconds. Was there a reason not to accept a Date do we know?
On 2 February 2015 at 09:55, Claus Ibsen <[email protected]> wrote: > Hi > > ActiveMQ has a scheduler on the client side, so you can delay sending > the message > http://activemq.apache.org/delay-and-schedule-message-delivery.html > > Also there is maybe something about setting a timestamp on the message > before the message is valid. Can't remember if there was something > like that in JMS spec, so you can say this message is only valid after > now + 10 sec. > > > > On Fri, Jan 30, 2015 at 4:28 PM, James Green <[email protected]> > wrote: > > We have a need to route message to a temporary location and to re-submit > > them every n seconds. > > > > We're thinking of sending the message to a queue if a later re-try is > > needed. > > > > A separate process would then be required to read from the queue and > > re-submit. This is fine but clearly listening on a queue is normally a > > constant process, so out of the box we'd get the message intended for > > re-try immediately and send it onwards for re-trying without any delay. > > > > It would be nice therefore to "wake up" a queue consumer after some sleep > > interval. Lets the background processes run that caused the need for a > > re-try. > > > > Any good way of achieving this? > > > > [ We have tried pushing them into a database and periodically pulling > them > > back out into the main process again, but we're hitting > > ConcurrentModificationExceptions which are proving difficult to > understand. > > ] > > > > Thanks, > > > > James > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: [email protected] > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/ >
