In this simple test, I'm having clients publishing/subscribing to amq.topic:

qpid-receive -b localhost:5670 -a amq.topic -f
qpid-send -b localhost:5672 -a amq.topic -m 1 --content-string "hello"

If Dispatch works, then in the future we plan to replace BrokerB with
Microsoft Azure Service Bus.

Thanks

On Fri, Aug 28, 2015 at 3:49 PM, Ted Ross <[email protected]> wrote:

>
>
> On 08/28/2015 04:42 PM, Ted Ross wrote:
>
>> What are you using the brokers for in this scenario?  Will you be
>> replacing BrokerB with another messaging intermediary or some consuming
>> process?
>>
>> I'm asking because your description says nothing about the configuration
>> of the brokers (besides the ports used).  Are you using queues and/or
>> topics on the brokers?
>>
>
> Perhaps a better question to ask is how are you publishing and subscribing
> in your test clients?
>
>
>
>> If you are able to describe your target scenario rather than an
>> intermediate testing scenario, it would be helpful.
>>
>> I should point out that in the Router configuration, "listener" and
>> "connector" refer to the way TCP/IP connections are established.
>> Listeners open passive ports for other processes to connect to and
>> connectors actively connect to other listening processes.
>>
>> -Ted
>>
>> On 08/28/2015 04:30 PM, jjw tectec wrote:
>>
>>> Hi Ted,
>>>
>>> My 2nd broker is running on a different port 5670 (command: ./qpidd -p
>>> 5670
>>> --data-dir /home/mmos/datadir/).
>>> So the scenario I'm trying to test is the following:
>>>
>>> Client_publisher -> BrokerA (port 5672) -> Router -> BrokerB (port
>>> 5670) ->
>>> Client_subscriber
>>>
>>> This is my first step in testing Dispatch Router. Once this is
>>> successful,
>>> my BrokerB will be replaced by something else.
>>>
>>> Can you please provide a config file that would make this scenario work?
>>>
>>> Thank you!
>>>
>>> jjw
>>>
>>> On Fri, Aug 28, 2015 at 3:10 PM, Ted Ross <[email protected]> wrote:
>>>
>>> Hi,
>>>>
>>>> Thanks for giving Dispatch Router a try.  I'm a little unclear as to
>>>> exactly what it is you are trying to do.
>>>>
>>>> It looks to me that you have both BrokerA and the Router listening on
>>>> port
>>>> 5672.  This is not going to work as whichever process you start first
>>>> will
>>>> get the port and the other will fail to open its listener.
>>>>
>>>> However, simply fixing this problem isn't going to make this work.  Can
>>>> you provide some more detail as to what you want to see?  Are there
>>>> specific queues or topics on the brokers that you are using?  What is
>>>> the
>>>> desired path for messages to flow along?
>>>>
>>>> Thanks,
>>>>
>>>> -Ted
>>>>
>>>>
>>>>
>>>> On 08/28/2015 03:00 PM, jjw tectec wrote:
>>>>
>>>> Hello,
>>>>>
>>>>> I'm trying to run a quick test using Dispatch Router, and I think I
>>>>> need
>>>>> help with configuration.
>>>>>
>>>>> I'd like to set up such a router between two AMQP brokers, and routes
>>>>> messages from BrokerA to BrokerB.
>>>>>
>>>>> Right now, I have Qpid BrokerA running on port 5672, and Qpid BrokerB
>>>>> running on port 5670, and I have a router running the following
>>>>> "qdrouterd.conf" config file content:
>>>>>
>>>>> listener {
>>>>>       addr: localhost
>>>>>       port: 5672
>>>>>       sasl-mechanisms: ANONYMOUS
>>>>> }
>>>>>
>>>>> connector {
>>>>>       addr: localhost
>>>>>       port: 5670
>>>>>       sasl-mechanisms: ANONYMOUS
>>>>> }
>>>>>
>>>>> router {
>>>>>       mode: standalone
>>>>> }
>>>>>
>>>>> Why doesn't the above config work with this simple scenario?
>>>>> I tested this broker+router setup using two clients: subscriber
>>>>> subscribing
>>>>> to port 5670, and publisher publishing to port 5672. Messages don't
>>>>> flow
>>>>> through...
>>>>>
>>>>> Thanks
>>>>>
>>>>> jjw
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to