Thanks. I am storing only the payload (it was an ObjectMessage).

I was able to resolve the issue by spawning a new thread to create my
singleton instance. I read the following from
http://docs.oracle.com/javaee/5/api/javax/jms/Session:

Once a connection has been started, any session with one or more registered
message listeners is dedicated to the thread of control that delivers
messages to it. It is erroneous for client code to use this session or any
of its constituent objects from another thread of control. The only
exception to this rule is the use of the session or connection close method.

Which led me to try the approach above. Happily, messages are now dequeuing
normally. :-)

Matt

On Fri, Feb 24, 2012 at 5:55 AM, Jakub Korab <jakub.ko...@gmail.com> wrote:

> Hi Matt,
>
> Yes message groups would do the job, as they guarantee that only one
> consumer is responsible for consuming that group. From the docs, they
> provide "guarranteed ordering of the processing of related messages across
> a
> single queue".
>
> I can't speak about your consumer code, but storing the entire JMS message
> in a cache seems like something that should be avoided. You should probably
> just be dealing with the message payload.
>
> Jakub
>
>
> Matt Lachman wrote
> >
> > Hi Jakub,
> >
> > Yes, from the queue on the broker. As far as the broker is concerned, it
> > remains "in-flight" permanently. What's weirder is when I run a
> standalone
> > java client to consume the messages, it has no trouble whatsoever. So I
> > think there's something going on in the client side that's causing
> > messages
> > not to be acknowledged.
> >
> > I have a manager class that is responsible for consuming & publishing to
> > the topic. The same manager class is responsible for consuming messages
> > from the queue. I have two nested listener classes which are instantiated
> > as member variables of the manager class in the constructor.
> >
> > I don't necessarily care about sequence; more that there is only ever one
> > message for a given id being processed at any given moment. Would message
> > groups still apply?
> >
> > Thanks,
> > Matt
> >
> > On Thu, Feb 23, 2012 at 9:41 AM, Jakub Korab &lt;jakub.korab@&gt; wrote:
> >
> >> Hi Matt,
> >>
> >> When you say that the message is not being dequeued, do you mean from
> the
> >> queue on the broker?
> >>
> >> The overall scheme itself seems to be pretty complicated; where are the
> >> topic messages coming from?
> >>
> >> If you are trying to ensure that messages for a particular id are
> >> consumed
> >> in sequence then perhaps message groups
> >> (http://activemq.apache.org/message-groups.html) might fit the bill
> >> better
> >> and simplify your code.
> >>
> >> Jakub
> >>
> >>
> >
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Queue-messages-not-dequeuing-tp4410892p4416812.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Reply via email to