Is multiple shared file lockers for multikahadb invalid?

[Devlin]

For ActiveMq 5.11, masterl/slave on NFSv4, is this broker configuration
invalid due to multiple shared lockers?



...







  








  








  






  






--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Selectors with virtual topics in broker networks

[Devlin]

Hi Tim,

Different hosts.

We used conditionalNetworkBridgeFilterFactory in the past, but removed it
months ago thinking it was causing a different issue, turned out to be
false, so we are considering enabling it again. What I don't like about this
filter is that it only kicks in on broker startup when no consumers are
active. If we set replayWhenNoConsumers="false", does the filter constantly
replay messages, irrespective of whether consumers exist or not?


  

  

  

  
 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Selectors with virtual topics in broker networks

[Devlin]

5.11.0

Trying to validate if our current setup is configured properly for virtual
topics with message selectors in a broker network. Based on preliminary
observations, virtual topics appear to works as expected; producers send on
topics, consumers receive on queues, regardless of where they reside in the
network. We did, however, observe the following problem:

Virtual topic producer sends 10 messages, consumer gets 7 messages, then we
kill the consumer to force a reconnect. When consumer connects back, the
remaining 3 messages are not forwarded to the consumer, they appear stuck on
the queue. If the producer sends new messages, the consumer, oddly, receives
the new messages.

I found this post, it suggests disabling conduit subs on queue connectors,
but enabling it on topic connectors (currently we disable it for both)
http://activemq.2283324.n4.nabble.com/conduit-subscriptions-td2365115.html#a2365117
 

## Virtual topic interceptor
## We deviated from standard virtual topic conventions due to our security
model, but it works 





## network connector
  
  




 




  





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Virtual destination subscription durability and message recovery

[Devlin]

Thanks, gtully!

Is our implementation for #1 correct? The assumption is by disabling removal
of inactive virtual destination queues, we effectively make them static
queues the moment they are created. So, assuming a producer publishes to
"topic://virtualTopics.mytopic" on BrokerA, if BrokerB has
queue://virtualTopics.mytopic.sub1" but no active consumers, will BrokerA
forward messages to BrokerB if the brokers are networked?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Virtual destination subscription durability and message recovery

[Devlin]

We've performed extensive testing with virtual destinations on 5.11 network
of brokers, it works well with two exceptions: 

#1 - subscription durability when consumers go offline,

#2 - producers publishing before consumers register their subscription

We manage to get around #1 by configuring producers to publish messages
using PERSISTENT delivery mode, then we disabled cleanup of inactive virtual
queues using wildcard destination policies. Now, when consumer who
previously created a virtual queue subscription go offline, newly-published
messages are retained on those queues until they are consumed, or expire;
that's good.

But #2 has proved challenging; we thought about using retroactive recovery
policies, but after reading the documentation we discovered it's not
reliable in broker networks. We're not sure how to proceed; unless there's a
way to retain messages in memory, or on disk, reliably for short periods of
time (basically recovery policy) and for an unknown number of durable
consumers, I suspect there is no solution to this problem.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Using failover with updateClusterClients, which one has precedence?

[Devlin]

Ok, that won't help because our network is full graph. From the client's
perspective, is there a way to see the most updated failover connection
list? We're using these methods, but it always shows brokers in what appears
to be alphabetic order.

BrokerInfo bInfo = connection.getBrokerInfo();
BrokerInfo[] brokers = bInfo.getPeerBrokerInfos();


Also, regarding updateClientFilter on the transport connector, we want to
filter brokers by region, our broker IDs are simple, eastbroker1,
eastbroker2, and westbroker1, westbroker2, etc. The pattern in the
documentation has this:

updateClusterFilter=".*A.*,.*B.*"

..which I think means any broker id containing 'A', and then any brokers
containing 'B', so for our case, we would tighten that up with the following
to select brokers starting with 'east', then brokers starting with 'west'...

updateClusterFilter="east.*,den.*"

Is that correct?







--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: brokerName and brokerId in network of brokers

[Devlin]

No, master/slave brokers, or any broker, participating in a network, should
never share names or IDs; they should be unique to each broker. I usually
make the brokerID and name the same for a single broker.

I asked a similar question last year, then answered it myself, hope this
helps:
https://stackoverflow.com/questions/32344317/activemq-5-11-network-of-brokers-and-master-slave-group-config



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Using failover with updateClusterClients, which one has precedence?

[Devlin]

The list of active brokers sent to clients, how is that list ordered?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Using failover with updateClusterClients, which one has precedence?

[Devlin]

ActiveMQ 5.11

When using failover URLs like this in a network of brokers where
updateClusterClients=true, how is failover handled?

failover:(tcp://hydra:61616,tcp://orion:61616,tcp://omega:61616,tcp://bigmoma:61616)?randomize=false

The behavior we're seeing is that, upon initial connect, the first host
(hydra) is selected, that's expected, but when the connection fails, the
client randomly connects to another broker in the list, not the second host
in the failover URL. So it appears updateClusterClients takes precedence
over the order by which hosts are configured in the failover URL, is that a
valid assumption? 





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Kahadb index updates taking too much time on ActiveMQ 5.11

[Devlin]

Thank you, Tim.

We finally figured out the issue; NFS "noac" option was killing performance.

(vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,noac,proto=tcp,port=0,timeo=20,retrans=2)

We joked about it afterwards, no "air conditioning" after a long summer can
kill anything :-)

Thanks again for your insight and pointers, will come in handy!



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Kahadb index updates taking too much time on ActiveMQ 5.11

[Devlin]

Samples for cpu self-time, total-time, and memory usage:

 

 

 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Should master/slave brokers share tmp_storage directory?

[Devlin]

It's my understanding with kahadb the store folder location is shared between
master and slave brokers using the following config:

   

   


Why is it that temp storage does not use the same, shared location? By
default, the location for tmp_storage appears to be local to the broker
itself:

2017-10-11 11:57:30,424 [AMQ-1-thread-1 ] INFO  PListStoreImpl
- PListStore:
[/opt/activemq/data/amqdata/seattlebroker-a1/tmp_storage] started
2017-10-11 11:57:30,603 [AMQ-1-thread-1 ] DEBUG KahaDBStore   
- Store OpenWire version configured as: 6

For master/slave broker groups, should the temp storage location be shared
with explicit config like this?

 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Is BrokerFilter a "blocking" interceptor?

[Devlin]

Thank you



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Is-BrokerFilter-a-blocking-interceptor-tp4720182p4720194.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Is BrokerFilter a "blocking" interceptor?

[Devlin]

We're experimenting with BrokerFilter to capture detailed info of producer,
consumer, message headers, etc., for logging and analysis, and want to be
very careful to avoid delaying or blocking the broker.

If a broker interceptor, for whatever reason, got stuck, would that block a
broker thread from continuing? 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Is-BrokerFilter-a-blocking-interceptor-tp4720182.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Virtual topics, custom prefix limitations

[Devlin]

We may need to support standard subscribers to the virtual topic, but it's
not a drop-dead requirement.
Having said that, we verified the broker network is working for standard
queues/topics using the above configuration, but not virtual topics, even
after removing . VT's are only working when producers
AND consumers are all connected to the same broker. 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717975.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Virtual topics, custom prefix limitations

[Devlin]

Ok, just to be clear, we define the virtual topic statically (the one used by
the producer), not the individual consumer queues. I hope it's the former
because client queues for virtual topics are named using "app-version"
convention for grouping related consumers; we can't define those names
statically as they're too volatile. Will report back on this.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717968.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Virtual topics, custom prefix limitations

[Devlin]

Tim,

The documentation on this topic (haha!) was never 100% clear to me. Here's
what we want to achieve given our architecture:

Topology

12 broker network (full-mesh)
All destinations dynamic (no static definitions)
Clients connect and reconnect with random brokers (preference to local)
AMQ 6.2.1 (preping for 6.3)

What we need
---
+ Virtual topics working in above architecture.
* Virtual topics to support queue *and* normal topic subscribers (can live
without this if duplication cannot be avoided)

It's my understanding AMQ 6.3 still uses ActiveMQ 5.11, bummer if that's
true, so as you said, we can't use useVirtualDestSubs broker params.

Question

If we statically-defined all virtual topics (we don't have many), can we
meet the requirements above?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717957.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Virtual topics, custom prefix limitations

[Devlin]

Hi Tim,

We managed to get working virtual topics in a 2 broker network, but only for
cases where producer and consumers are using the same broker; consumers
connected to the broker where the producer is not present did not receive
messages. We confirmed the network functions as expected for standard
topics/queues, but not for virtual topics.

I found this in the docs, looks interesting, not sure if it would help, but
regardless, it's for 5.13, we're on 5.11.
   
 .
  

Here's our config:
   








   










   




 



  

  

  

  
  
  

  
  

  






--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717887.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Virtual topics, custom prefix limitations

[Devlin]

When customizing virtual topic consumer "prefix", can I use wildcards?

I know this works:





..not sure if this /would/ work:








--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Network of embedded brokers with MuleESB as JVM

[Devlin]

Hello,

Wondering if anyone has successfully used embedded brokers in a network,
possibly with MuleESB as the JVM container, (any JVM is fine too, would love
to hear your experience)

My questions:

Do embedded brokers function just the same as standalone brokers?
Can the JVM use VM to communicate with embedded broker while not sacrificing
network capabilities of the broker should it need to forward/receive
messages to/from remote brokers?  

thank
Dev



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Network-of-embedded-brokers-with-MuleESB-as-JVM-tp4682218.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.