We need this one badly because it breaks all possibilities for message
expiration on durable topics. I would provide a fix but I am lacking
sufficient understanding of the code flow around cursors and the message
store ;-)
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f234180
Thanks for the confirmation, I have opened
https://issues.apache.org/jira/browse/AMQ-6863 and added a Java class that
reproduces the issue.
Tomas
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
I am using a file based cursor with durable topic subscriptions because in my
tests the broker would run out of memory when dealing with large numbers of
messages without an active consumer.
I have run into a NullPointerException when the messages meant for the topic
with an active durable subscrip
I have opened an issue for this and added a unit test that reproduces the
problem to it:
https://issues.apache.org/jira/browse/AMQ-6784
Tomas
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Duplicate-messages-received-with-ActiveMQ-5-13-2-tp4728627p4729221.html
Sent from
Looks like this was a dead end. I found the reason I needed to start the
connectors was because I added them after the broker was already running. I
guess if you add them before you start the broker then you don't need to
start them explicitly...
Tomas
--
View this message in context:
http://a
I know nothing about static destinations but one thing I noticed in your
Github code: when you add network and transport connectors, you do not start
them. I tested this with one of my sample ActiveMQ programs and if I don't
start the connectors then there are no messages flowing.
Try to use:
org
It looks like the check for networkSubscription is there for a reason,
described in https://issues.apache.org/jira/browse/AMQ-2327
The commit 6c5732b also mentions:
/key is not to conduit proxy/proxy consumers b/c the dependencies cannot be
easily resolved without more network traffic on additions
I think I am confusing things by describing the problem with words, so here
is a plain ActiveMQ implementation that reproduces the problem. If I run
this, I send one message and receive four instead of the expected two.
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.active
I finally understand where the conduit should happen. I was of the impression
that the conduit happens in broker B (hub) when subscriptions come from C
and D. But that can't happen because there are two bridges (B-C and B-D) and
conduit needs to happen within one bridge.
The conduit needs to happen
I got a little further today:
The reason that conduit does not happen is that even though ConsumerInfos
come twice for the same topic, they come over different transport
connections and thus come to different bridges. For conduit to happen it
must happen within one bridge.
Also, I noticed that when
In my broker "B" which is the hub in the hub & spoke topology, and in
org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
There is this code:
protected boolean addToAlreadyInterestedConsumers(ConsumerInfo info) {
// search through existing subscriptions and see if we
I figured out why I am not seeing ConsumerInfo coming: it comes in wrapped in
ActiveMQMessage (an advisory message) and the ConsumerInfo is contained
within as a dataStructure.
I don't know why conduit is not happening but I can now trace the code flow
to within ConduitBridge.
--
View this mess
BTW here is where I am getting stuck:
I was assuming that brokers must somehow learn about consumers on other
brokers. I looked at the code of org.apache.activemq.network.ConduitBridge
and later org.apache.activemq.network.DemandForwardingBridge and it seemed
to me that the means by which the broke
The tables I sent before have a row named "Number of consumers". These are
from org.apache.activemq.broker.jmx.DestinationViewMBean#getConsumerCount
I also put a breakpoint in org.apache.activemq.broker.region.Topic#dispatch
And logged the number of consumers
(org.apache.activemq.broker.region.Top
I double checked just to make sure:
There is this code in org.apache.activemq.network.NetworkBridgeFactory
public static DemandForwardingBridge
createBridge(NetworkBridgeConfiguration configuration,
Transport
localTransport, Transport remo
I plan to debug further, but right now I have statistics for one message sent
from A to topic T. This is best shown in a table, but I don't want to mess
up formatting in email clients, so here it is in CSV:
With audit on:
audit on,A,B,C,D,,
Enqueue count,1,2,1,1
Dequeue count,2,2,1,1
Dispatch cou
I can now reliably reproduce the duplication and I can prevent it. However,
the behavior leaves me a bit puzzled:
The issue is that the broker adds the message twice to the subscription, via
org.apache.activemq.broker.region.TopicSubscription#add
There is a check for duplicate messages,
org.apach
Sorry, I messed up my boolean logic when I wrote my reply. I meant to write
that I have verified that my conduitSubscriptions is set to TRUE so this
should not be the cause. By mistake I have typed false...
I'll try to watch the the enqueue counts to see if I can figure out the
origin.
Thanks,
T
I am using just regular topics. In my example above C and D connect to their
embedded brokers via VM transport, create a consumer and register a
listener.
I have debugged it just to make sure and conduitSubscriptions are set to
false, i.e. org.apache.activemq.network.NetworkBridgeFactory#createBri
I have a problem where I produce a TextMessage to a topic and the consumer
receives it twice. I only have one system where I can reproduce this and I
would appreciate any tips on how to debug this further.
I have four JVMs, let's call them A, B, C and D. Each one runs an ActiveMQ
broker. The conne
20 matches
Mail list logo
