activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: JMS message ID set based on sequence and overwrites the client specified JMS message id?
Date Sun, 05 Apr 2015 15:34:04 GMT
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" <burton@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 <johndament@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 <burton@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>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message