Stop testing with a producer; it's completely irrelevant. Messages traverse a network of brokers because they are pulled by consumers, not because they are pushed by producers. So everything you need to know about the operation of a network of brokers can be determined by examining the interaction of consumers and brokers; producers don't matter.
Delete the destination from both brokers, then do the test that describe to you. On Oct 1, 2015 7:58 AM, <barry.barn...@wellsfargo.com> wrote: > So the client connected to brokerB and put a message, but this created a > queue called TEST as well. Now we have queue TEST on broker A and queue > TEST on brokerB as well. So the listener on BrokerA is listening to TEST > queue on BrokerA, and no one is listening to TEST queue on BrokerB. Do I > need to configure something differently? Or does the client not need to > specify creating a dynamic queue called TEST? > > Regards, > > Barry > > > -----Original Message----- > From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain > Sent: Thursday, October 01, 2015 9:13 AM > To: ActiveMQ Users > Subject: RE: Network of Brokers - Putting/Getting from a queue > > On Oct 1, 2015 7:02 AM, <barry.barn...@wellsfargo.com> wrote: > > > > Have you disabled advisory messages and/or explicitly included/excluded > any destinations? > > I have added nothing in the activemq.xml file to exclude advisory > messages, etc. > > > > And have you done anything to prevent the broker from auto-creating > destinations? > > Again, nothing added to the activemq.xml file. Do I need to add > something? Is there a parm I need to add for auto-creation? > > No, it's default behavior; the question was whether you'd disabled it. > > > If I add a queue called TEST on brokerA, it does not appear on brokerB. > Should it? > > No. Instead, it should be created on A when a consumer subscribes to it on > B. Does that happen? > > > When both brokers are up and you connect the consumer to broker B, broker > B should register itself as a consumer on broker A. You can confirm > whether this is happening by attaching a JMX viewer such as JConsole to > broker A and navigating to the destinations to confirm that the destination > has been created on A and that B is a consumer on it. > > Should I see the same queue name on both Brokers? > > Yes, and one consumer listed under it on each broker. > > > > > Regards, > > > > Barry > > > > > > -----Original Message----- > > From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain > > Sent: Thursday, October 01, 2015 8:56 AM > > To: ActiveMQ Users > > Subject: RE: Network of Brokers - Putting/Getting from a queue > > > > Your assumption is correct, networks of brokers allow messages to be > forwarded across the network to be consumed by consumers on brokers other > than the one on which the message was produced. > > > > Have you disabled advisory messages and/or explicitly included/excluded > any destinations? And have you done anything to prevent the broker from > auto-creating destinations? If so, please describe what you've done, > because that could explain what you're seeing. > > > > When both brokers are up and you connect the consumer to broker B, broker > B should register itself as a consumer on broker A. You can confirm > whether this is happening by attaching a JMX viewer such as JConsole to > broker A and navigating to the destinations to confirm that the destination > has been created on A and that B is a consumer on it. > > > > Tim > > On Oct 1, 2015 5:58 AM, <barry.barn...@wellsfargo.com> wrote: > > > > > Here's the issue we are having: > > > > > > Broker A > > > Broker B > > > Network Connector to Broker B Network > > > Connector to Broker A > > > (Broker A discovers Network Connector in Log) (Broker B discovers > > > Network Connector in Log) > > > Queue: TEST defined here > > > > > > Application A puts message on queue TEST - Success Application B > > > connects to Broker B and performs a 'read' on queue TEST > > > > > > No success reading from queue TEST > > > > > > The assumption is that Application B can read from destination TEST if > > > it connects on Broker B, even though the queue is defined on Broker A. > > > Is my assumption incorrect? If so, how do we accomplish this design? > > > > > > > > > Regards, > > > > > > Barry > > > > > > > > > -----Original Message----- > > > From: Basmajian, Raffi [mailto:rbasmaj...@ofiglobal.com] > > > Sent: Wednesday, September 30, 2015 3:07 PM > > > To: users@activemq.apache.org > > > Subject: RE: Network of Brokers - Putting/Getting from a queue > > > > > > Barry, > > > > > > No, not from the client perspective, there is no special designation. > > > Provided <networkConnectors> config permits message flow between A and > > > B, messages should flow in the direction of the connector config. > > > > > > Raffi > > > > > > > > > -----Original Message----- > > > From: barry.barn...@wellsfargo.com > > > [mailto:barry.barn...@wellsfargo.com] > > > Sent: Wednesday, September 30, 2015 2:24 PM > > > To: users@activemq.apache.org > > > Subject: Network of Brokers - Putting/Getting from a queue [ EXTERNAL > > > ] > > > Importance: High > > > > > > If we have 2 brokers defined in a network together, and we define a > > > queue on broker A, and an application connects to Broker B to put a > > > message on that queue, should the message just go there? Do we need > > > to specify that it is a 'network' queue? > > > > > > Regards, > > > > > > Barry > > > > > > > > > This e-mail transmission may contain information that is proprietary, > > > privileged and/or confidential and is intended exclusively for the > > > person(s) to whom it is addressed. Any use, copying, retention or > > > disclosure by any person other than the intended recipient or the > > > intended recipient's designees is strictly prohibited. If you are not > > > the intended recipient or their designee, please notify the sender > > > immediately by return e-mail and delete all copies. OppenheimerFunds > > > may, at its sole discretion, monitor, review, retain and/or disclose > > > the content of all email communications. > > > >
