The first one may be a nice way.
Pagination: count the queue size, view the section.
You neednt care about headers or whole messages.
http://weibo.com/kimmking
From: Marco Zapletal [via ActiveMQ]
Date: 2012-12-04 22:11
To: kimmking
Subject: Strategy for browsing a DLQ containing a high numb
How do I remove the old connection in a proper way?
Just calling removeConnection with the old context and old info does not
deactivate the durable subscriptions. if I then call removeConsumers so that
the durable subscriptions get deactivated results to strange reconnect
behaviour: everytime I
On Sun, 2012-12-02 at 07:39 -0800, mercuric wrote:
> Hi,
> can u maybe give me some more informations what i should check?
> Some more informations:
> - Windows 7 Prof, SP1, 32Bit
> - Microsoft Cisual C++ 2010 (10.30319.1)
> - MS Win SDK for Win7 (7.1)
> > IncludeDirectories:
> > a. ../activemq-
Thanks for the answer.
That's what I see:
+ Producer and consumer are working OK with "DESARROLLO.DATA" queue.
+ Consumer is unregistered from destination after killing it
+ Producer freezes trying to send next message.
+ I Stop producer and start it again.
+ Producer sends message to other queue
Hi folks,
I am thinking about an appropriate strategy for browsing the DLQ from a
Web application, whereby it is assumed that the DLQ potentially contains
a high number of (large) messages. Browsing should support pagination
(similar to databases) as well as loading only the headers during
b
With the async property what i do find is that the message is persisted in
the local store and then when the Active MQ link is restored the message
goes from the producer/broker to ActiveMQ server and then to the received.
This works for me as the only message loss is see is if my producer server
useAsyncSend will force the producer to send asynchronously even if the
message is persistent. This may not be desired as the client won't wait for
the broker to respond with an Ack saying the message is persisted in the
store.
You could try lowering the inactivity monitor. The default is 3.
?
This should not happen.
If you enable debug logging in the broker, you should see that the transactions
is rolled back when the client disconnects as part of killing it.
Other consumers should still have access to the destination and should be able
to consume messages.
Can you check using jcon
Hi Christian,
I think this shouldn't happen as message on its arrival goes to every
subscription and then is dispatched from there. So if messages arrive
in the same order in the topics they should later on be dispatched in
that same order.
Regards
--
Dejan Bosanac
--
Red Hat,
I have the next situation:
+ An ActiveMQ stand alone Broker.
+ A JMS message producer sending 1MB message to a queue named "DATA" in a
non transactional mode.
+ A JMS message consumer reading in transactional mode from the same queue.
The consumer reads a message and then write it to a file. If i
10 matches
Mail list logo