I'm still investigating the cause of the dead lock. Here's a piece of thread
dump I found from the producer broker. * Note producer broker configures the
NetworkConnector..
"ActiveMQ Transport: tcp://lod-uimlongda/10.130.156.161:61616@45650" #139
prio=5 os_prio=0 tid=0x7fddc0007800 nid=0x1a1a
Hi Art and Tim
Thanks very much for your replies. It's a good point you mentioned this
design could be an anti-pattern.
Just to give more background for our use case. The main purpose of our
product is to collect data from LAN or WAN network devices. And the
collectors (producers) will push colle
As Art said, the typical configuration is to have one standalone broker
that all clients (producers and consumers) connect to, that is available
even when the clients are not. This won't work if the clients frequently
are up but don't have network connectivity, or if no one is willing to host
and
When you say TempStore, are you talking about storing non-persistent messages
specifically?
To answer your question - YES, the hub broker, and all brokers in the
network can hold messages during short periods of disconnects between
clients. That's kinda the main point of JMS and messaging middlew
Hi Tim
The main reason we put a broker on the producer is we want to leverage the
broker's TempStore feature. Which is if the Consumer is offline, all the
producer's broker can temporarily hold the produced data, and once the
consumer is back online, it will catch up.
This is the design since we
You have to do what you described, and attempt to connect to all the client
brokers from the hub, which means you have to list them all out up front
and then live with the log messages when the hub can't connect to a spoke
broker because the spoke is offline. That's the more-complicated
configurat
Thanks for the response Tim!
I would not mind to go with more complicated config as long as it works.
Just my experience on AMQ config is very basic. I've seen some examples of
using two non-duplex network connectors for 1-to-1 brokers. But I didn't
find out similar examples for 1-to-many brokers.
You can use two non-duplex connections, one from each broker. This is
advantageous in some network configurations (e.g a pair of brokers) because
it lets you reuse the same configuration on multiple brokers (with a little
placeholder substitution) and disadvantageous in others (e.g. a
hub-and-spok
