> On 1 Aug 2017, at 15:36, tpavelka wrote:
>
> 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
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
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
Wait, there are multiple transport connections between A and B? Why? That
right there seems like a problem, and might be the root cause of the
behavior you're seeing.
The code I see in that processBrokerInfo() method creates the inverse side
of the duplex network connection (under the hood it's no
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
Can you set a breakpoint at ConduitBridge:60 and see whether
info.isNetworkSubscription() evaluates to true (i.e. whether you go into
the then block, and therefore return false)? If I'm understanding that code
correctly, I think that may be the reason why the connections aren't being
conduited.
Ti
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
Sorry, I was so focused on the difference between the enqueue and dequeue
counts that I missed that row in your earlier post.
So that confirms that despite using a DurableConduitBridge, the
subscriptions are not actually being combined, which is indeed what I was
asking. (And yes, your understandi
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 don't know of another place where it would be configured, so I think the
more likely explanation is that there's a bug causing the second
subscription to not be conduited onto the first.
But let's first let's confirm that we actually have two subscriptions on A
(because if we don't, then somethi
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
Those stats clearly show that the duplication occurs when forwarding from A
to B, so my question of whether conduitSubscriptions is in use for that
link is even more pertinent. My guess is that you'll find that it's not,
and that enabling it fixes this behavior.
Tim
On Jul 26, 2017 7:13 AM, "tpav
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't answer question #2, so I asked the dev list if someone could answer
it.
For #1, what you're seeing is not expected when conduitSubscriptions is in
use. In fact, this behavior is expected when someone fails to use
conduitSubscriptions, so it's odd that you're seeing it with
conduitSubscript
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
If you set conduitSubscriptions to true, does the behavior become the
expected behavior? If so, you can read a description of why having it false
would cause this to happen halfway down
http://activemq.apache.org/networks-of-brokers.html.
You can determine where the duplication occurs by watching
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
Do you have conduitSubscriptions set to false for your networkConnectors?
Or are your topics virtual and you're dynamically including both the topic
and the consumer queues?
Both of those could result in duplicate messages on a topic.
Tim
On Jul 18, 2017 6:36 AM, "tpavelka" wrote:
> I have a
23 matches
Mail list logo
