What's your volume of destinations, and how much churn do you have?
Another user (Kevin Burton) experienced inefficiency in the destination GC
algorithm with large numbers of short-lived destinations; if that sounds
like your situation, I think he had some changes that never made it to
trunk,
Greetings,
I am pretty new to ActiveMQ as we just deployed into our stack.
We had a network of brokers have a significant problem tonight due to (what
appeared to be) a single broker. 2 of the 3 were processing messages OK and
the third was queuing up and not processing messages quickly. This
Nothing on that one either, so I assume they're being stripped off
somewhere along the way. Can you put the screenshot online (either on a
site you have an account on that allows that, or on something anonymous
like imagebin.ca) and send the link?
Tim
On Sep 14, 2016 10:32 AM,
Hello Tim
Yes that is exactly what I was looking for. Hard to know it was so simple...
Well you're right. Reading error messages let me think it was necessary to
give listener up prior to unsubscribe, but I found a post explaining it was
possible to unsuscribe after doing a
Which DLQ plugin are you referring to? And what do you expect it would do
vs. what it's actually doing?
Also, do I understand correctly that these messages are expiring (i.e. you
set a JMSExpiration header when producing messages, and that time arrives
without consuming them)?
Tim
On Sep 14,
Hi Experts,
In my application which uses activemq-cpp-2.2.3 crashes with below dump-
(gdb) bt
#0 0x7f6a84d4b625 in raise () from /lib64/libc.so.6
#1 0x7f6a84d4ce05 in abort () from /lib64/libc.so.6
#2 0x7f6a811d9e8d in ?? () from xxx/libdbtasks16_r.so
#3
#4 0x0062a168
Dear All,
I am newbie to ActiveMQ. I have a producer which sents out messages to the
broker (using failoverurl). I want those messages not to expired and sent to
dlq. But as DLQ plugin is disabled, messages are still dequeued ( expired).
Why? Is this the default behaviour of activemq to dequeue
Calling TopicSubscriber.setMessageListener(null) will unset the listener;
is that what you're looking for?
Also, you say that "Before they may do so, I need to remove the
MessageListener;" why is this necessary prior to unsubscribing?
Tim
On Sep 13, 2016 12:34 PM, "Lovegiver"
Hi
After upgrading from a 5.12.x version to 5.14.0, it looks like
ActiveMQServiceFactory,
instantiating the Spring application context, has a problem accessing the Spring
schema and resorts to trying to access the Internet.
Any ideas what could have changed that's causing this unwanted remote
Mike,
You referenced a screenshot that showed behavior that wasn't standard for
debugging, but it wasn't attached. Could you share that again? I've
assumed in the rest of this response that the debugging session is working
fine but that you're simply not hitting your breakpoint, but if what you
10 matches
Mail list logo