This sounds like application logic to me. It's the broker's job to try to prevent re-delivery of the same message, but it's not the broker's job to identify that two messages have similar content. That's the job of the consumer of your messages, using whatever heuristics are most appropriate to your domain.
Also, I'd probably focus on avoiding processing the second message once it's received, rather than on avoiding sending it, but that will ultimately depend on where you have access to the information that will let you evaluate your domain-specific heuristics. On Mon, Oct 20, 2014 at 6:13 PM, Kevin Burton <bur...@spinn3r.com> wrote: > Are there any decent strategies to prevent sending the same message to the > queue twice? > > Say for example it’s a money transfer … if you initiate the transfer twice > you’d transfer too much money. If you have an algorithm that retries you > would want it to NOT enqueue the message transfer message again because > it’s already pending. > > And additionally, how would this be done with delayed messages? This is > more of a fake queue so browsing the main queue wouldn’t show the messages > in the delayed queue. > > -- > > Founder/CEO Spinn3r.com > Location: *San Francisco, CA* > blog: http://burtonator.wordpress.com > … or check out my Google+ profile > <https://plus.google.com/102718274791889610666/posts> > <http://spinn3r.com> >
