Is multiple shared file lockers for multikahadb invalid?

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

Re: Selectors with virtual topics in broker networks

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

Selectors with virtual topics in broker networks

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

Re: Virtual destination subscription durability and message recovery

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

Virtual destination subscription durability and message recovery

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

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

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();

Re: brokerName and brokerId in network of brokers

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:

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

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?

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

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

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

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

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

Should master/slave brokers share tmp_storage directory?

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

Re: Is BrokerFilter a "blocking" interceptor?

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?

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

Re: Virtual topics, custom prefix limitations

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

Re: Virtual topics, custom prefix limitations

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

Re: Virtual topics, custom prefix limitations

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)

Re: Virtual topics, custom prefix limitations

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

Virtual topics, custom prefix limitations

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 -

Network of embedded brokers with MuleESB as JVM

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