I think you'd be better off implementing this in the consumer as a Map<your ID, Date first received> with a periodic task to remove IDs that are more than N seconds old. I'm assuming you're only try to prevent dupes within a certain time window; avoiding them forever could use a HashSet but I'd worry about OOMing, so hopefully a limited time window is good enough.
If you implement this in the broker, 1) you don't protect against a duplicate message sent after the consumer has processed the first one, and 2) you tax the broker's memory, rather than putting the burden on the consumer (and it would be a lighter burden for the consumer because the consumer only has to worry about messages destined for it). Tim On Apr 4, 2015 9:11 PM, "Kevin Burton" <bur...@spinn3r.com> wrote: > I already have a task on my list to implement priority in the memory > store. So once I start that work, in theory , I could implement some sort > of (optional) functionality to support unique messages since they’re > already in the hash table. > > Something like JMS.PrimaryKey or JMS.UniqueIdentifier. > > Totally proprietary of course but basically if the header isn’t set the > memory store would behave as normal. > > Thoughts not this feature? I’d like to land it eventually but I guess if > there’s a strong -1 for this what I could do is just make a small patch > that I can land and build my own proprietary ActiveMQ. But at least at > that point I would get JMS priorities. > > > > On Sat, Apr 4, 2015 at 4:46 PM, John D. Ament <johndam...@apache.org> > wrote: > > > Hi Kevin, > > > > I think from the spec's perspective the behavior you're seeing is the > > expected behavior. > > > > > > > https://jms-spec.java.net/2.0/apidocs/javax/jms/Message.html#setJMSMessageID(java.lang.String) > > > > Basically, we intend this method to be used only by the implementor, not > > the client. > > > > I know what your next question might be - why does the JMS spec expose > > methods that should only be used by implementors? > > > > Well, we thought about removing methods like this, deprecating them, etc. > > We couldn't do things that would break backwards compatibility. This > > method is used when you have two implementors running in parallel, say > you > > have ActiveMQ side by side with HornetQ and you wanted to bridge messages > > between the two. HornetQ may need to override the message ID going into > > their system. (Just an example). > > > > John > > > > On Sat, Apr 4, 2015 at 7:09 PM, Kevin Burton <bur...@spinn3r.com> wrote: > > > > > I’m trying to generate unique message IDs so that I can idempotently > > > produce messages from our ‘loader’ so that items don’t get processed > more > > > than once. > > > > > > The JMS Message ID should do that .. but it looks like when I call > > > producer.send() it’s ALWAYs overwritten by a custom message ID: > > > > > > > > > In ActiveMQSession.send it just overwrites it: > > > > > > msg.setMessageId(new > > MessageId(producer.getProducerInfo().getProducerId(), > > > sequenceNumber)); > > > > > > … so no matter WHAT I want to send , it’s just overwritten. > > > > > > I’m really hoping I’m doing something or that this is just a bug > because > > it > > > would be a shame to lose this feature. > > > > > > -- > > > > > > 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> > > > > > > > > > -- > > 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> >
