You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2013/09/16 22:57:27 UTC
Introducing Qpid Dispatch Router
I've been working on a sub-project within Apache Qpid called Qpid
Dispatch Router. I'd like to invite use, participation, feedback,
criticism, etc.
There are a couple of basic introductory points to be made:
* Dispatch Router is built on top of the Qpid Proton engine and driver
APIs (The C implementations thereof).
* A router is not a broker. The idea of a message router was born
from the awkwardness of trying to build scaled-up messaging networks
out of brokers.
* A network built from routers provides interconnect between brokers,
between clients and brokers, or between clients and clients (i.e.
point-to-point non-brokered).
* The message router brings together the two separate worlds of
Messaging and Networking. Such a confluence was made possible by
the AMQP 1.0 protocol. The vision is to provide a messaging
interconnect that has all the advanced semantics of AMQP along with
the scale, resiliency, and ease of deployment of an IP network.
The code is in early stages of development and has not been through any
kind of release. It builds only in Posix-based environments (Linux,
etc.) and it only functions as a single stand-alone router at present
(inter-router links are not yet fully implemented). The router can be
used with both the Proton Messenger API and the Qpid Messaging Client
APIs that support AMQP 1.0 (and, in theory, with any AMQP 1.0 endpoint).
The code can be found in the Subversion tree under "qpid/extras/dispatch".
http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch
There is a draft web page for it here:
http://qpid.apache.org/components/dispatch-router/index.html
Qpid Dispatch Router will provide two basic mechanisms for message
routing. *Message Routing* forwards individual messages to their
destination(s) based on the address in the message's "to" field. *Link
Routing* propagates link-attaches across the network to the peer
addressed in the link's "source" or "target" field. This is similar to
creating a "virtual channel" across the network and allows the full
semantics (transactions, flow-control, etc.) to be provided end-to-end
(as though the participating endpoints were directly connected).
Currently, only Message Routing is implemented.
The following is a brief example of the router's use to illustrate how
it works:
[Refer to the README file for building instructions]
[The router executable and Proton Messenger examples are assumed to be
in the execution path]
Run the following in separate terminal windows:
$ router/dispatch-router -c <path-to-config-file>
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/another
$ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
$ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
The first line starts the router process (assumed to be configured to
listen on port 5672). The "recv" examples create connections to the
router and subscribe to two different address (two use the same
address). The "send" examples create connections to the router and send
messages to their respective addresses.
If everything works, the first sent message will be received by the
first two receivers and the second sent message will be received only by
the third receiver.
Regards,
-Ted
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
On 09/25/2013 07:49 AM, Gordon Sim wrote:
> On 09/16/2013 09:57 PM, Ted Ross wrote:
>> The following is a brief example of the router's use to illustrate how
>> it works:
>>
>> [Refer to the README file for building instructions]
>> [The router executable and Proton Messenger examples are assumed to be
>> in the execution path]
>>
>> Run the following in separate terminal windows:
>>
>> $ router/dispatch-router -c <path-to-config-file>
>> $ recv amqp://0.0.0.0:5672/my_address/1
>> $ recv amqp://0.0.0.0:5672/my_address/1
>> $ recv amqp://0.0.0.0:5672/my_address/another
>> $ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
>> $ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
>
> You can also run a similar example using the qpid::messaging examples
> (assuming amqpc.so loaded and libqpid-proton found):
>
> drain -f --connection-options {protocol:amqp1.0} abc
> drain -f --connection-options {protocol:amqp1.0} abc
> drain -f --connection-options {protocol:amqp1.0} xyz
> spout --content one --connection-options {protocol:amqp1.0} -P
> x-amqp-to=abc ignored
> spout --content two --connection-options {protocol:amqp1.0} -P
> x-amqp-to=xyz ignored
>
> At present the router works off the 'to' field in the message which is
> not set by default for the qpid::messaging library, rather than the
> target address for the sender link.
I've raised an issue against Dispatch to fix this problem:
https://issues.apache.org/jira/browse/QPID-5175
>
> Also, the address format that qpid::messaging uses treats an unquoted
> '/' as the divider between node and subject, so if you want to use the
> exact same addresses as in Ted's example above you need to ensure they
> are quoted e.g. drain -f --connection-options {protocol:amqp1.0}
> "'my_address/1'", so that the whole is taken as the source.
>
>> The first line starts the router process (assumed to be configured to
>> listen on port 5672). The "recv" examples create connections to the
>> router and subscribe to two different address (two use the same
>> address). The "send" examples create connections to the router and send
>> messages to their respective addresses.
>>
>> If everything works, the first sent message will be received by the
>> first two receivers and the second sent message will be received only by
>> the third receiver.
>
> The same behaviour should be seen.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 09/16/2013 09:57 PM, Ted Ross wrote:
> The following is a brief example of the router's use to illustrate how
> it works:
>
> [Refer to the README file for building instructions]
> [The router executable and Proton Messenger examples are assumed to be
> in the execution path]
>
> Run the following in separate terminal windows:
>
> $ router/dispatch-router -c <path-to-config-file>
> $ recv amqp://0.0.0.0:5672/my_address/1
> $ recv amqp://0.0.0.0:5672/my_address/1
> $ recv amqp://0.0.0.0:5672/my_address/another
> $ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
> $ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
You can also run a similar example using the qpid::messaging examples
(assuming amqpc.so loaded and libqpid-proton found):
drain -f --connection-options {protocol:amqp1.0} abc
drain -f --connection-options {protocol:amqp1.0} abc
drain -f --connection-options {protocol:amqp1.0} xyz
spout --content one --connection-options {protocol:amqp1.0} -P
x-amqp-to=abc ignored
spout --content two --connection-options {protocol:amqp1.0} -P
x-amqp-to=xyz ignored
At present the router works off the 'to' field in the message which is
not set by default for the qpid::messaging library, rather than the
target address for the sender link.
Also, the address format that qpid::messaging uses treats an unquoted
'/' as the divider between node and subject, so if you want to use the
exact same addresses as in Ted's example above you need to ensure they
are quoted e.g. drain -f --connection-options {protocol:amqp1.0}
"'my_address/1'", so that the whole is taken as the source.
> The first line starts the router process (assumed to be configured to
> listen on port 5672). The "recv" examples create connections to the
> router and subscribe to two different address (two use the same
> address). The "send" examples create connections to the router and send
> messages to their respective addresses.
>
> If everything works, the first sent message will be received by the
> first two receivers and the second sent message will be received only by
> the third receiver.
The same behaviour should be seen.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by NimbusParc <ni...@yahoo.in>.
Ted Ross wrote
> I think you are somehow linking against an old proton library.
Yes, i just removed the proton-0.4 and re-installed proton-0.5. Now
qpid-dispatch built without any errors.
Ted Ross wrote
> On 09/18/2013 12:54 AM, NimbusParc wrote:
>> yes, libqpid-proton.so.2.0.0
>>
>>
>> Ted Ross wrote
>>> pn_connector_name was introduced in Proton 0.5. What version of the .so
>>> file do you have installed? Is it libqpid-proton.so.2?
>>>
>>> -Ted
>>>
>>> On 09/17/2013 05:58 AM, NimbusParc wrote:
>>>> Yes, i installed the latest proton libraries (0.5) and also cmake build
>>>> configuration to point proton .so files.
>>>> As shown below, In my CMakeCache.txt..
>>>>
>>>> //Path to a library.
>>>> proton_lib:FILEPATH=/usr/lib64/libqpid-proton.so
>>>>
>>>> After adding the path of .so files, which are in proton-c/ directory
>>>> to
>>>> *
>>>> LD_LIBRARY_PATH *. And then running make again.
>>>> I am getting this error while linking to the c shared library *
>>>> libqpid-dispatch.so *. Results given below..
>>>>
>>>> Scanning dependencies of target qpid-dispatch
>>>> [ 3%] Building C object CMakeFiles/qpid-dispatch.dir/src/agent.c.o
>>>> [ 6%] Building C object CMakeFiles/qpid-dispatch.dir/src/alloc.c.o
>>>> ....
>>>> ....
>>>> [ 63%] Building C object
>>>> CMakeFiles/qpid-dispatch.dir/src/work_queue.c.o
>>>> Linking C shared library libqpid-dispatch.so
>>>> CMakeFiles/qpid-dispatch.dir/src/server.c.o: In function
>>>> `thread_process_listeners':
>>>> server.c:(.text+0x285): undefined reference to `pn_connector_name'
>>>> collect2: ld returned 1 exit status
>>>> make[2]: *** [libqpid-dispatch.so.0.1] Error 1
>>>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>>>> make: *** [all] Error 2
>>>>
>>>> Gordon Sim wrote
>>>>> On 09/17/2013 07:59 AM, NimbusParc wrote:
>>>>>> Error while doing make ..
>>>>>>
>>>>>> dispatch/src/server.c: In function ‘thread_process_listeners’:
>>>>>> dispatch/src/server.c:103: error: implicit declaration of function
>>>>>> ‘pn_connector_name’
>>>>>> make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
>>>>>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>>>>>> make: *** [all] Error 2
>>>>> Do you have the latest proton libraries (0.5) and is the cmake build
>>>>> configured to point at them?
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> users-unsubscribe@.apache
>>>>> For additional commands, e-mail:
>>>>> users-help@.apache
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598230.html
>>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>> users-unsubscribe@.apache
>>>> For additional commands, e-mail:
>>> users-help@.apache
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>>> users-help@.apache
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598248.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>> For additional commands, e-mail:
> users-help@.apache
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598286.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
I just re-tested this without any problem.
I downloaded qpid-proton 0.5 from here:
http://qpid.apache.org/releases/qpid-proton-0.5/index.html
After building and installing qpid-proton, qpid-dispatch built without
any errors.
I think you are somehow linking against an old proton library.
-Ted
On 09/18/2013 12:54 AM, NimbusParc wrote:
> yes, libqpid-proton.so.2.0.0
>
>
> Ted Ross wrote
>> pn_connector_name was introduced in Proton 0.5. What version of the .so
>> file do you have installed? Is it libqpid-proton.so.2?
>>
>> -Ted
>>
>> On 09/17/2013 05:58 AM, NimbusParc wrote:
>>> Yes, i installed the latest proton libraries (0.5) and also cmake build
>>> configuration to point proton .so files.
>>> As shown below, In my CMakeCache.txt..
>>>
>>> //Path to a library.
>>> proton_lib:FILEPATH=/usr/lib64/libqpid-proton.so
>>>
>>> After adding the path of .so files, which are in proton-c/ directory to
>>> *
>>> LD_LIBRARY_PATH *. And then running make again.
>>> I am getting this error while linking to the c shared library *
>>> libqpid-dispatch.so *. Results given below..
>>>
>>> Scanning dependencies of target qpid-dispatch
>>> [ 3%] Building C object CMakeFiles/qpid-dispatch.dir/src/agent.c.o
>>> [ 6%] Building C object CMakeFiles/qpid-dispatch.dir/src/alloc.c.o
>>> ....
>>> ....
>>> [ 63%] Building C object CMakeFiles/qpid-dispatch.dir/src/work_queue.c.o
>>> Linking C shared library libqpid-dispatch.so
>>> CMakeFiles/qpid-dispatch.dir/src/server.c.o: In function
>>> `thread_process_listeners':
>>> server.c:(.text+0x285): undefined reference to `pn_connector_name'
>>> collect2: ld returned 1 exit status
>>> make[2]: *** [libqpid-dispatch.so.0.1] Error 1
>>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>>> make: *** [all] Error 2
>>>
>>> Gordon Sim wrote
>>>> On 09/17/2013 07:59 AM, NimbusParc wrote:
>>>>> Error while doing make ..
>>>>>
>>>>> dispatch/src/server.c: In function ‘thread_process_listeners’:
>>>>> dispatch/src/server.c:103: error: implicit declaration of function
>>>>> ‘pn_connector_name’
>>>>> make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
>>>>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>>>>> make: *** [all] Error 2
>>>> Do you have the latest proton libraries (0.5) and is the cmake build
>>>> configured to point at them?
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@.apache
>>>> For additional commands, e-mail:
>>>> users-help@.apache
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598230.html
>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>> users-help@.apache
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> users-unsubscribe@.apache
>> For additional commands, e-mail:
>> users-help@.apache
>
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598248.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by NimbusParc <ni...@yahoo.in>.
yes, libqpid-proton.so.2.0.0
Ted Ross wrote
> pn_connector_name was introduced in Proton 0.5. What version of the .so
> file do you have installed? Is it libqpid-proton.so.2?
>
> -Ted
>
> On 09/17/2013 05:58 AM, NimbusParc wrote:
>> Yes, i installed the latest proton libraries (0.5) and also cmake build
>> configuration to point proton .so files.
>> As shown below, In my CMakeCache.txt..
>>
>> //Path to a library.
>> proton_lib:FILEPATH=/usr/lib64/libqpid-proton.so
>>
>> After adding the path of .so files, which are in proton-c/ directory to
>> *
>> LD_LIBRARY_PATH *. And then running make again.
>> I am getting this error while linking to the c shared library *
>> libqpid-dispatch.so *. Results given below..
>>
>> Scanning dependencies of target qpid-dispatch
>> [ 3%] Building C object CMakeFiles/qpid-dispatch.dir/src/agent.c.o
>> [ 6%] Building C object CMakeFiles/qpid-dispatch.dir/src/alloc.c.o
>> ....
>> ....
>> [ 63%] Building C object CMakeFiles/qpid-dispatch.dir/src/work_queue.c.o
>> Linking C shared library libqpid-dispatch.so
>> CMakeFiles/qpid-dispatch.dir/src/server.c.o: In function
>> `thread_process_listeners':
>> server.c:(.text+0x285): undefined reference to `pn_connector_name'
>> collect2: ld returned 1 exit status
>> make[2]: *** [libqpid-dispatch.so.0.1] Error 1
>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Gordon Sim wrote
>>> On 09/17/2013 07:59 AM, NimbusParc wrote:
>>>> Error while doing make ..
>>>>
>>>> dispatch/src/server.c: In function ‘thread_process_listeners’:
>>>> dispatch/src/server.c:103: error: implicit declaration of function
>>>> ‘pn_connector_name’
>>>> make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
>>>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>>>> make: *** [all] Error 2
>>> Do you have the latest proton libraries (0.5) and is the cmake build
>>> configured to point at them?
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>>> users-help@.apache
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598230.html
>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>> For additional commands, e-mail:
> users-help@.apache
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598248.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
pn_connector_name was introduced in Proton 0.5. What version of the .so
file do you have installed? Is it libqpid-proton.so.2?
-Ted
On 09/17/2013 05:58 AM, NimbusParc wrote:
> Yes, i installed the latest proton libraries (0.5) and also cmake build
> configuration to point proton .so files.
> As shown below, In my CMakeCache.txt..
>
> //Path to a library.
> proton_lib:FILEPATH=/usr/lib64/libqpid-proton.so
>
> After adding the path of .so files, which are in proton-c/ directory to *
> LD_LIBRARY_PATH *. And then running make again.
> I am getting this error while linking to the c shared library *
> libqpid-dispatch.so *. Results given below..
>
> Scanning dependencies of target qpid-dispatch
> [ 3%] Building C object CMakeFiles/qpid-dispatch.dir/src/agent.c.o
> [ 6%] Building C object CMakeFiles/qpid-dispatch.dir/src/alloc.c.o
> ....
> ....
> [ 63%] Building C object CMakeFiles/qpid-dispatch.dir/src/work_queue.c.o
> Linking C shared library libqpid-dispatch.so
> CMakeFiles/qpid-dispatch.dir/src/server.c.o: In function
> `thread_process_listeners':
> server.c:(.text+0x285): undefined reference to `pn_connector_name'
> collect2: ld returned 1 exit status
> make[2]: *** [libqpid-dispatch.so.0.1] Error 1
> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
> make: *** [all] Error 2
>
> Gordon Sim wrote
>> On 09/17/2013 07:59 AM, NimbusParc wrote:
>>> Error while doing make ..
>>>
>>> dispatch/src/server.c: In function ‘thread_process_listeners’:
>>> dispatch/src/server.c:103: error: implicit declaration of function
>>> ‘pn_connector_name’
>>> make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
>>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>>> make: *** [all] Error 2
>> Do you have the latest proton libraries (0.5) and is the cmake build
>> configured to point at them?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> users-unsubscribe@.apache
>> For additional commands, e-mail:
>> users-help@.apache
>
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598230.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by NimbusParc <ni...@yahoo.in>.
Yes, i installed the latest proton libraries (0.5) and also cmake build
configuration to point proton .so files.
As shown below, In my CMakeCache.txt..
//Path to a library.
proton_lib:FILEPATH=/usr/lib64/libqpid-proton.so
After adding the path of .so files, which are in proton-c/ directory to *
LD_LIBRARY_PATH *. And then running make again.
I am getting this error while linking to the c shared library *
libqpid-dispatch.so *. Results given below..
Scanning dependencies of target qpid-dispatch
[ 3%] Building C object CMakeFiles/qpid-dispatch.dir/src/agent.c.o
[ 6%] Building C object CMakeFiles/qpid-dispatch.dir/src/alloc.c.o
....
....
[ 63%] Building C object CMakeFiles/qpid-dispatch.dir/src/work_queue.c.o
Linking C shared library libqpid-dispatch.so
CMakeFiles/qpid-dispatch.dir/src/server.c.o: In function
`thread_process_listeners':
server.c:(.text+0x285): undefined reference to `pn_connector_name'
collect2: ld returned 1 exit status
make[2]: *** [libqpid-dispatch.so.0.1] Error 1
make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
make: *** [all] Error 2
Gordon Sim wrote
> On 09/17/2013 07:59 AM, NimbusParc wrote:
>> Error while doing make ..
>>
>> dispatch/src/server.c: In function ‘thread_process_listeners’:
>> dispatch/src/server.c:103: error: implicit declaration of function
>> ‘pn_connector_name’
>> make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
>> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
>> make: *** [all] Error 2
>
> Do you have the latest proton libraries (0.5) and is the cmake build
> configured to point at them?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598230.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 09/17/2013 07:59 AM, NimbusParc wrote:
> Error while doing make ..
>
> dispatch/src/server.c: In function ‘thread_process_listeners’:
> dispatch/src/server.c:103: error: implicit declaration of function
> ‘pn_connector_name’
> make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
> make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
> make: *** [all] Error 2
Do you have the latest proton libraries (0.5) and is the cmake build
configured to point at them?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by NimbusParc <ni...@yahoo.in>.
Error while doing make ..
dispatch/src/server.c: In function ‘thread_process_listeners’:
dispatch/src/server.c:103: error: implicit declaration of function
‘pn_connector_name’
make[2]: *** [CMakeFiles/qpid-dispatch.dir/src/server.c.o] Error 1
make[1]: *** [CMakeFiles/qpid-dispatch.dir/all] Error 2
make: *** [all] Error 2
Ted Ross wrote
> I've been working on a sub-project within Apache Qpid called Qpid
> Dispatch Router. I'd like to invite use, participation, feedback,
> criticism, etc.
>
> There are a couple of basic introductory points to be made:
>
> * Dispatch Router is built on top of the Qpid Proton engine and driver
> APIs (The C implementations thereof).
> * A router is not a broker. The idea of a message router was born
> from the awkwardness of trying to build scaled-up messaging networks
> out of brokers.
> * A network built from routers provides interconnect between brokers,
> between clients and brokers, or between clients and clients (i.e.
> point-to-point non-brokered).
> * The message router brings together the two separate worlds of
> Messaging and Networking. Such a confluence was made possible by
> the AMQP 1.0 protocol. The vision is to provide a messaging
> interconnect that has all the advanced semantics of AMQP along with
> the scale, resiliency, and ease of deployment of an IP network.
>
> The code is in early stages of development and has not been through any
> kind of release. It builds only in Posix-based environments (Linux,
> etc.) and it only functions as a single stand-alone router at present
> (inter-router links are not yet fully implemented). The router can be
> used with both the Proton Messenger API and the Qpid Messaging Client
> APIs that support AMQP 1.0 (and, in theory, with any AMQP 1.0 endpoint).
>
> The code can be found in the Subversion tree under "qpid/extras/dispatch".
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch
>
> There is a draft web page for it here:
>
> http://qpid.apache.org/components/dispatch-router/index.html
>
> Qpid Dispatch Router will provide two basic mechanisms for message
> routing. *Message Routing* forwards individual messages to their
> destination(s) based on the address in the message's "to" field. *Link
> Routing* propagates link-attaches across the network to the peer
> addressed in the link's "source" or "target" field. This is similar to
> creating a "virtual channel" across the network and allows the full
> semantics (transactions, flow-control, etc.) to be provided end-to-end
> (as though the participating endpoints were directly connected).
> Currently, only Message Routing is implemented.
>
> The following is a brief example of the router's use to illustrate how
> it works:
>
> [Refer to the README file for building instructions]
> [The router executable and Proton Messenger examples are assumed to be
> in the execution path]
>
> Run the following in separate terminal windows:
>
> $ router/dispatch-router -c
> <path-to-config-file>
> $ recv amqp://0.0.0.0:5672/my_address/1
> $ recv amqp://0.0.0.0:5672/my_address/1
> $ recv amqp://0.0.0.0:5672/my_address/another
> $ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
> $ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
>
> The first line starts the router process (assumed to be configured to
> listen on port 5672). The "recv" examples create connections to the
> router and subscribe to two different address (two use the same
> address). The "send" examples create connections to the router and send
> messages to their respective addresses.
>
> If everything works, the first sent message will be received by the
> first two receivers and the second sent message will be received only by
> the third receiver.
>
> Regards,
>
> -Ted
--
View this message in context: http://qpid.2158936.n2.nabble.com/Introducing-Qpid-Dispatch-Router-tp7598222p7598228.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
On 09/27/2013 01:09 AM, Mitsuru Oka wrote:
> 2013/9/25 Ted Ross <tr...@redhat.com>:
>> Load-balanced fan-out is not currently implemented but is something that I
>> consider a key feature. I'd be interested to hear if you have specific
>> requirements for how it works.
>>
>> One interesting request I've heard is to be able to establish groups of
>> consumers for a "topic". A message will be delivered to one consumer within
>> each group. In other words, messages are broadcast to all groups but are
>> load-balanced within each group.
> Ted, if you have any plan/roadmap to implement a kind of load
> balancing feature, could you share that information?
This is a high-priority feature. I'll get a roadmap put up on the web
page sometime soon.
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Mitsuru Oka <ok...@gmail.com>.
2013/9/25 Ted Ross <tr...@redhat.com>:
> Load-balanced fan-out is not currently implemented but is something that I
> consider a key feature. I'd be interested to hear if you have specific
> requirements for how it works.
>
> One interesting request I've heard is to be able to establish groups of
> consumers for a "topic". A message will be delivered to one consumer within
> each group. In other words, messages are broadcast to all groups but are
> load-balanced within each group.
Ted, if you have any plan/roadmap to implement a kind of load
balancing feature, could you share that information?
Thanks,
--
Mitsuru Oka
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
On 09/25/2013 09:20 AM, Gordon Sim wrote:
> On 09/25/2013 02:14 PM, Ted Ross wrote:
>> Load-balanced fan-out is not currently implemented but is something that
>> I consider a key feature. I'd be interested to hear if you have
>> specific requirements for how it works.
>
> What about selective subscriptions e.g. sub-topic matching or wildcard
> matching?
This is another interesting question. To the extent that the
subscription selectors can be aggregated into a superset selector, I
think Dispatch could do a pretty good job with this. For more
sophisticated matching (i.e. content-based, etc.) you would probably
want to put a broker into the mix.
>
>> One interesting request I've heard is to be able to establish groups of
>> consumers for a "topic". A message will be delivered to one consumer
>> within each group. In other words, messages are broadcast to all groups
>> but are load-balanced within each group.
>
> That is like shared subscriptions in qpidd (but obviously more
> distributed).
Yes, this is possible with qpidd by fanning-out to multiple queues (one
per group) and then having the group members all subscribe to the same
queue.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 09/25/2013 02:14 PM, Ted Ross wrote:
> Load-balanced fan-out is not currently implemented but is something that
> I consider a key feature. I'd be interested to hear if you have
> specific requirements for how it works.
What about selective subscriptions e.g. sub-topic matching or wildcard
matching?
> One interesting request I've heard is to be able to establish groups of
> consumers for a "topic". A message will be delivered to one consumer
> within each group. In other words, messages are broadcast to all groups
> but are load-balanced within each group.
That is like shared subscriptions in qpidd (but obviously more distributed).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 09/26/2013 05:03 AM, Mitsuru Oka wrote:
> Another question on Dispatch router is there.
>
> Could you show me an example of request-reply/response pattern via
> Dispatch router using proton messenger based sender and receiver? I
> tried proton client/server python example, but the client couldn't
> receive reply message from server.
>
> $ dispatch-router -c qpid-dispatch.conf
> $ ./server.py amqp://0.0.0.0/topic
> $ ./client.py amqp://0.0.0.0/topic subject
>
> server output:
> amqp://b0f56a1c-573c-42e0-8c6f-46d5735b2301/replies
> Dispatched subject None
>
> client output:
> <nothing and blocking>
I know this is not what you asked for, but just in case its interesting
to you or anyone else reading the thread, attached is a request-response
example using qpid::messaging that works with the dispatch router.
It does contain a few modifications compared with the example shipped
with the qpid::messaging client (see changes, also attached) to get
around https://issues.apache.org/jira/browse/QPID-5175 and to avoid
requesting a dynamic reply queue.
Re: Introducing Qpid Dispatch Router
Posted by Mitsuru Oka <ok...@gmail.com>.
2013/9/26 Ted Ross <tr...@redhat.com>:
> First, modify your client line to include a reply-to address.
>
>
> $ dispatch-router -c qpid-dispatch.conf
> $ ./server.py amqp://0.0.0.0/topic
> $ ./client.py -r amqp://0.0.0.0/reply amqp://0.0.0.0/topic subject
>
>
> You will also need to apply the following patch to client.py. The reason
> this patch is necessary is that the client/server example is written only
> for the point-to-point case (no intermediary).
Thanks a lot! This works for me too.
Gordon's qpid::messaging request-reply example is also informative to
understand what was changed between amqp0-10 and amqp1.0.
--
Mitsuru Oka
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Reply-To Addresses (was Re: Introducing Qpid Dispatch Router)
Posted by Gordon Sim <gs...@redhat.com>.
On 09/26/2013 03:28 PM, Ted Ross wrote:
>
> On 09/26/2013 08:23 AM, Gordon Sim wrote:
>> On 09/26/2013 01:14 PM, Ted Ross wrote:
>>> I'm putting a feature into Dispatch that allows a client to dynamically
>>> obtain a routable reply-to address. This will involve changes in
>>> Messenger as well.
>>
>> I'd be interested in hearing a bit more about that, with a view to
>> making any necessary changes to the qpid::messaging library also.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> Here's how it looks from a protocol perspective:
>
> Server or
> Client First Intermediary
> | |
> |-- Attach Sender ------------------>|
> |<- Attach ---------------------------|
> | |
> |-- Attach Receiver (src=_dyn_) ----->|
> |<- Attach (src=<temp>) --------------|
> | |
> |-- Xfr (to=SVC, reply-to=<temp>) --->|
> | |
> |<- Xfr (to=<temp>) ------------------|
> | |
>
> The client creates a pair of links, one to send the request and one to
> receive the response. The source-terminus of the response link is
> flagged as dynamic. The peer then assigns a temporary source address to
> the link. This address is valid for the life of the link. This
> temporary address can then be used as a reply-to in the request message.
Great, that will work already with qpid::messaging. Indeed that is how
the unmodified client example works (which I've successfully tested
again both Qpid brokers, ActiveMQ and HornetQ).
> From an API perspective, it would be nice to hide as much of this
> detail as possible from the user. It might be sufficient to allow a
> message to be tagged as "expecting a reply". The client library could
> then do what is needed to set up the reply link and insert the reply-to
> field into the message.
>
> -Ted
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Reply-To Addresses (was Re: Introducing Qpid Dispatch Router)
Posted by Gordon Sim <gs...@redhat.com>.
On 09/26/2013 03:28 PM, Ted Ross wrote:
>
> On 09/26/2013 08:23 AM, Gordon Sim wrote:
>> On 09/26/2013 01:14 PM, Ted Ross wrote:
>>> I'm putting a feature into Dispatch that allows a client to dynamically
>>> obtain a routable reply-to address. This will involve changes in
>>> Messenger as well.
>>
>> I'd be interested in hearing a bit more about that, with a view to
>> making any necessary changes to the qpid::messaging library also.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> Here's how it looks from a protocol perspective:
>
> Server or
> Client First Intermediary
> | |
> |-- Attach Sender ------------------>|
> |<- Attach ---------------------------|
> | |
> |-- Attach Receiver (src=_dyn_) ----->|
> |<- Attach (src=<temp>) --------------|
> | |
> |-- Xfr (to=SVC, reply-to=<temp>) --->|
> | |
> |<- Xfr (to=<temp>) ------------------|
> | |
>
> The client creates a pair of links, one to send the request and one to
> receive the response. The source-terminus of the response link is
> flagged as dynamic. The peer then assigns a temporary source address to
> the link. This address is valid for the life of the link. This
> temporary address can then be used as a reply-to in the request message.
Ok, that would already work with qpid::messaging. Indeed its the same
approach that is used with other brokers including both Qpid brokers,
ActiveMQ and HornetQ (the client/server example now runs against all these).
> From an API perspective, it would be nice to hide as much of this
> detail as possible from the user. It might be sufficient to allow a
> message to be tagged as "expecting a reply". The client library could
> then do what is needed to set up the reply link and insert the reply-to
> field into the message.
>
> -Ted
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Reply-To Addresses (was Re: Introducing Qpid Dispatch Router)
Posted by Ted Ross <tr...@redhat.com>.
On 09/26/2013 08:23 AM, Gordon Sim wrote:
> On 09/26/2013 01:14 PM, Ted Ross wrote:
>> I'm putting a feature into Dispatch that allows a client to dynamically
>> obtain a routable reply-to address. This will involve changes in
>> Messenger as well.
>
> I'd be interested in hearing a bit more about that, with a view to
> making any necessary changes to the qpid::messaging library also.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Here's how it looks from a protocol perspective:
Server or
Client First Intermediary
| |
|-- Attach Sender ------------------>|
|<- Attach ---------------------------|
| |
|-- Attach Receiver (src=_dyn_) ----->|
|<- Attach (src=<temp>) --------------|
| |
|-- Xfr (to=SVC, reply-to=<temp>) --->|
| |
|<- Xfr (to=<temp>) ------------------|
| |
The client creates a pair of links, one to send the request and one to
receive the response. The source-terminus of the response link is
flagged as dynamic. The peer then assigns a temporary source address to
the link. This address is valid for the life of the link. This
temporary address can then be used as a reply-to in the request message.
From an API perspective, it would be nice to hide as much of this
detail as possible from the user. It might be sufficient to allow a
message to be tagged as "expecting a reply". The client library could
then do what is needed to set up the reply link and insert the reply-to
field into the message.
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 09/26/2013 01:14 PM, Ted Ross wrote:
> I'm putting a feature into Dispatch that allows a client to dynamically
> obtain a routable reply-to address. This will involve changes in
> Messenger as well.
I'd be interested in hearing a bit more about that, with a view to
making any necessary changes to the qpid::messaging library also.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
On 09/26/2013 12:03 AM, Mitsuru Oka wrote:
> Another question on Dispatch router is there.
>
> Could you show me an example of request-reply/response pattern via
> Dispatch router using proton messenger based sender and receiver? I
> tried proton client/server python example, but the client couldn't
> receive reply message from server.
>
> $ dispatch-router -c qpid-dispatch.conf
> $ ./server.py amqp://0.0.0.0/topic
> $ ./client.py amqp://0.0.0.0/topic subject
>
> server output:
> amqp://b0f56a1c-573c-42e0-8c6f-46d5735b2301/replies
> Dispatched subject None
>
> client output:
> <nothing and blocking>
>
>
> Thanks,
> Mitsuru Oka
>
The request-reply pattern needs a bit of work. I'm putting a feature
into Dispatch that allows a client to dynamically obtain a routable
reply-to address. This will involve changes in Messenger as well.
In the mean time, you can make it work by doing the following:
First, modify your client line to include a reply-to address.
$ dispatch-router -c qpid-dispatch.conf
$ ./server.py amqp://0.0.0.0/topic
$ ./client.py -r amqp://0.0.0.0/reply amqp://0.0.0.0/topic subject
You will also need to apply the following patch to client.py. The reason
this patch is necessary is that the client/server example is written
only for the point-to-point case (no intermediary).
$ svn diff client.py
Index: client.py
===================================================================
--- client.py (revision 1520149)
+++ client.py (working copy)
@@ -41,15 +41,16 @@
msg.subject = subject
msg.reply_to = opts.reply_to
+mng.subscribe(opts.reply_to)
+
mng.put(msg)
mng.send()
-if opts.reply_to[:2] == "~/":
- mng.recv(1)
- try:
- mng.get(msg)
- print msg.address, msg.subject
- except Exception, e:
- print e
+mng.recv(1)
+try:
+ mng.get(msg)
+ print msg.address, msg.subject
+except Exception, e:
+ print e
mng.stop()
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Mitsuru Oka <ok...@gmail.com>.
Another question on Dispatch router is there.
Could you show me an example of request-reply/response pattern via
Dispatch router using proton messenger based sender and receiver? I
tried proton client/server python example, but the client couldn't
receive reply message from server.
$ dispatch-router -c qpid-dispatch.conf
$ ./server.py amqp://0.0.0.0/topic
$ ./client.py amqp://0.0.0.0/topic subject
server output:
amqp://b0f56a1c-573c-42e0-8c6f-46d5735b2301/replies
Dispatched subject None
client output:
<nothing and blocking>
Thanks,
Mitsuru Oka
2013/9/26 Ted Ross <tr...@redhat.com>:
> This sounds like a good use case for Dispatch Router. Please let me know if
> there is any way I can be of help to you.
>
> -Ted
>
>
> On 09/25/2013 10:18 AM, Mitsuru Oka wrote:
>>
>> I am considering use of Dispatch Router for asynchronous task queue like
>> Celery framework. But Celery is based on a broker such as RabbitMQ. I just
>> dont want to use such the heavy broker, because the task is no need to be
>> durable. So, the Dispatch Router is relative good choice for me.
>>
>> If two or more tasks are there, I would use multiple topics for the tasks.
>> Currently, I have no plan touse the group of consumers.
>>
>> Thanks,
>> Mitsuru Oka
>> 2013/09/25 22:14 "Ted Ross" <tr...@redhat.com>:
>>
>>> Load-balanced fan-out is not currently implemented but is something that
>>> I
>>> consider a key feature. I'd be interested to hear if you have specific
>>> requirements for how it works.
>>>
>>> One interesting request I've heard is to be able to establish groups of
>>> consumers for a "topic". A message will be delivered to one consumer
>>> within each group. In other words, messages are broadcast to all groups
>>> but are load-balanced within each group.
>>>
>>> -Ted
>>>
>>> On 09/25/2013 03:48 AM, Mitsuru Oka wrote:
>>>
>>>> Hello, I'm new to Proton and Dispatch router.
>>>>
>>>> I'd like to know if the Dispatch Router support more complex patterns
>>>> such as pub-sub. Especially, whether load balanced routing to
>>>> subscribe node is implemented or not is my interesting point.
>>>>
>>>> Thanks,
>>>> Mitsuru Oka
>>>>
>>>>
>>>> 2013/9/17 Ted Ross <tr...@redhat.com>:
>>>>
>>>>> I've been working on a sub-project within Apache Qpid called Qpid
>>>>> Dispatch
>>>>> Router. I'd like to invite use, participation, feedback, criticism,
>>>>> etc.
>>>>>
>>>>> There are a couple of basic introductory points to be made:
>>>>>
>>>>> * Dispatch Router is built on top of the Qpid Proton engine and
>>>>> driver
>>>>> APIs (The C implementations thereof).
>>>>> * A router is not a broker. The idea of a message router was born
>>>>> from the awkwardness of trying to build scaled-up messaging
>>>>> networks
>>>>> out of brokers.
>>>>> * A network built from routers provides interconnect between
>>>>> brokers,
>>>>> between clients and brokers, or between clients and clients (i.e.
>>>>> point-to-point non-brokered).
>>>>> * The message router brings together the two separate worlds of
>>>>> Messaging and Networking. Such a confluence was made possible by
>>>>> the AMQP 1.0 protocol. The vision is to provide a messaging
>>>>> interconnect that has all the advanced semantics of AMQP along
>>>>> with
>>>>> the scale, resiliency, and ease of deployment of an IP network.
>>>>>
>>>>> The code is in early stages of development and has not been through any
>>>>> kind
>>>>> of release. It builds only in Posix-based environments (Linux, etc.)
>>>>> and it
>>>>> only functions as a single stand-alone router at present (inter-router
>>>>> links
>>>>> are not yet fully implemented). The router can be used with both the
>>>>> Proton
>>>>> Messenger API and the Qpid Messaging Client APIs that support AMQP 1.0
>>>>> (and,
>>>>> in theory, with any AMQP 1.0 endpoint).
>>>>>
>>>>> The code can be found in the Subversion tree under
>>>>> "qpid/extras/dispatch".
>>>>>
>>>>>
>>>>> http://svn.apache.org/repos/**asf/qpid/trunk/qpid/extras/**dispatch<http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch>
>>>>>
>>>>>
>>>>> There is a draft web page for it here:
>>>>>
>>>>>
>>>>> http://qpid.apache.org/**components/dispatch-router/**index.html<http://qpid.apache.org/components/dispatch-router/index.html>
>>>>>
>>>>>
>>>>> Qpid Dispatch Router will provide two basic mechanisms for message
>>>>> routing.
>>>>> *Message Routing* forwards individual messages to their destination(s)
>>>>> based
>>>>> on the address in the message's "to" field. *Link Routing* propagates
>>>>> link-attaches across the network to the peer addressed in the link's
>>>>> "source" or "target" field. This is similar to creating a "virtual
>>>>> channel"
>>>>> across the network and allows the full semantics (transactions,
>>>>> flow-control, etc.) to be provided end-to-end (as though the
>>>>> participating
>>>>> endpoints were directly connected). Currently, only Message Routing is
>>>>> implemented.
>>>>>
>>>>> The following is a brief example of the router's use to illustrate how
>>>>> it
>>>>> works:
>>>>>
>>>>> [Refer to the README file for building instructions]
>>>>> [The router executable and Proton Messenger examples are assumed to be
>>>>> in
>>>>> the execution path]
>>>>>
>>>>> Run the following in separate terminal windows:
>>>>>
>>>>> $ router/dispatch-router -c <path-to-config-file>
>>>>> $ recv
>>>>> amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>
>>>>> $ recv
>>>>> amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>
>>>>> $ recv
>>>>> amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another>
>>>>> $ send -a
>>>>> amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>CONTENT
>>>>> $ send -a
>>>>> amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another>CONTENT
>>>>>
>>>>>
>>>>> The first line starts the router process (assumed to be configured to
>>>>> listen
>>>>> on port 5672). The "recv" examples create connections to the router
>>>>> and
>>>>> subscribe to two different address (two use the same address). The
>>>>> "send"
>>>>> examples create connections to the router and send messages to their
>>>>> respective addresses.
>>>>>
>>>>> If everything works, the first sent message will be received by the
>>>>> first
>>>>> two receivers and the second sent message will be received only by the
>>>>> third
>>>>> receiver.
>>>>>
>>>>> Regards,
>>>>>
>>>>> -Ted
>>>>>
>>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
>>>
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
Mitsuru Oka
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
This sounds like a good use case for Dispatch Router. Please let me
know if there is any way I can be of help to you.
-Ted
On 09/25/2013 10:18 AM, Mitsuru Oka wrote:
> I am considering use of Dispatch Router for asynchronous task queue like
> Celery framework. But Celery is based on a broker such as RabbitMQ. I just
> dont want to use such the heavy broker, because the task is no need to be
> durable. So, the Dispatch Router is relative good choice for me.
>
> If two or more tasks are there, I would use multiple topics for the tasks.
> Currently, I have no plan touse the group of consumers.
>
> Thanks,
> Mitsuru Oka
> 2013/09/25 22:14 "Ted Ross" <tr...@redhat.com>:
>
>> Load-balanced fan-out is not currently implemented but is something that I
>> consider a key feature. I'd be interested to hear if you have specific
>> requirements for how it works.
>>
>> One interesting request I've heard is to be able to establish groups of
>> consumers for a "topic". A message will be delivered to one consumer
>> within each group. In other words, messages are broadcast to all groups
>> but are load-balanced within each group.
>>
>> -Ted
>>
>> On 09/25/2013 03:48 AM, Mitsuru Oka wrote:
>>
>>> Hello, I'm new to Proton and Dispatch router.
>>>
>>> I'd like to know if the Dispatch Router support more complex patterns
>>> such as pub-sub. Especially, whether load balanced routing to
>>> subscribe node is implemented or not is my interesting point.
>>>
>>> Thanks,
>>> Mitsuru Oka
>>>
>>>
>>> 2013/9/17 Ted Ross <tr...@redhat.com>:
>>>
>>>> I've been working on a sub-project within Apache Qpid called Qpid
>>>> Dispatch
>>>> Router. I'd like to invite use, participation, feedback, criticism, etc.
>>>>
>>>> There are a couple of basic introductory points to be made:
>>>>
>>>> * Dispatch Router is built on top of the Qpid Proton engine and driver
>>>> APIs (The C implementations thereof).
>>>> * A router is not a broker. The idea of a message router was born
>>>> from the awkwardness of trying to build scaled-up messaging networks
>>>> out of brokers.
>>>> * A network built from routers provides interconnect between brokers,
>>>> between clients and brokers, or between clients and clients (i.e.
>>>> point-to-point non-brokered).
>>>> * The message router brings together the two separate worlds of
>>>> Messaging and Networking. Such a confluence was made possible by
>>>> the AMQP 1.0 protocol. The vision is to provide a messaging
>>>> interconnect that has all the advanced semantics of AMQP along with
>>>> the scale, resiliency, and ease of deployment of an IP network.
>>>>
>>>> The code is in early stages of development and has not been through any
>>>> kind
>>>> of release. It builds only in Posix-based environments (Linux, etc.)
>>>> and it
>>>> only functions as a single stand-alone router at present (inter-router
>>>> links
>>>> are not yet fully implemented). The router can be used with both the
>>>> Proton
>>>> Messenger API and the Qpid Messaging Client APIs that support AMQP 1.0
>>>> (and,
>>>> in theory, with any AMQP 1.0 endpoint).
>>>>
>>>> The code can be found in the Subversion tree under
>>>> "qpid/extras/dispatch".
>>>>
>>>> http://svn.apache.org/repos/**asf/qpid/trunk/qpid/extras/**dispatch<http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch>
>>>>
>>>> There is a draft web page for it here:
>>>>
>>>> http://qpid.apache.org/**components/dispatch-router/**index.html<http://qpid.apache.org/components/dispatch-router/index.html>
>>>>
>>>> Qpid Dispatch Router will provide two basic mechanisms for message
>>>> routing.
>>>> *Message Routing* forwards individual messages to their destination(s)
>>>> based
>>>> on the address in the message's "to" field. *Link Routing* propagates
>>>> link-attaches across the network to the peer addressed in the link's
>>>> "source" or "target" field. This is similar to creating a "virtual
>>>> channel"
>>>> across the network and allows the full semantics (transactions,
>>>> flow-control, etc.) to be provided end-to-end (as though the
>>>> participating
>>>> endpoints were directly connected). Currently, only Message Routing is
>>>> implemented.
>>>>
>>>> The following is a brief example of the router's use to illustrate how it
>>>> works:
>>>>
>>>> [Refer to the README file for building instructions]
>>>> [The router executable and Proton Messenger examples are assumed to be in
>>>> the execution path]
>>>>
>>>> Run the following in separate terminal windows:
>>>>
>>>> $ router/dispatch-router -c <path-to-config-file>
>>>> $ recv amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>
>>>> $ recv amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>
>>>> $ recv amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another>
>>>> $ send -a amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>CONTENT
>>>> $ send -a amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another>CONTENT
>>>>
>>>> The first line starts the router process (assumed to be configured to
>>>> listen
>>>> on port 5672). The "recv" examples create connections to the router and
>>>> subscribe to two different address (two use the same address). The
>>>> "send"
>>>> examples create connections to the router and send messages to their
>>>> respective addresses.
>>>>
>>>> If everything works, the first sent message will be received by the first
>>>> two receivers and the second sent message will be received only by the
>>>> third
>>>> receiver.
>>>>
>>>> Regards,
>>>>
>>>> -Ted
>>>>
>>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Mitsuru Oka <ok...@gmail.com>.
I am considering use of Dispatch Router for asynchronous task queue like
Celery framework. But Celery is based on a broker such as RabbitMQ. I just
dont want to use such the heavy broker, because the task is no need to be
durable. So, the Dispatch Router is relative good choice for me.
If two or more tasks are there, I would use multiple topics for the tasks.
Currently, I have no plan touse the group of consumers.
Thanks,
Mitsuru Oka
2013/09/25 22:14 "Ted Ross" <tr...@redhat.com>:
> Load-balanced fan-out is not currently implemented but is something that I
> consider a key feature. I'd be interested to hear if you have specific
> requirements for how it works.
>
> One interesting request I've heard is to be able to establish groups of
> consumers for a "topic". A message will be delivered to one consumer
> within each group. In other words, messages are broadcast to all groups
> but are load-balanced within each group.
>
> -Ted
>
> On 09/25/2013 03:48 AM, Mitsuru Oka wrote:
>
>> Hello, I'm new to Proton and Dispatch router.
>>
>> I'd like to know if the Dispatch Router support more complex patterns
>> such as pub-sub. Especially, whether load balanced routing to
>> subscribe node is implemented or not is my interesting point.
>>
>> Thanks,
>> Mitsuru Oka
>>
>>
>> 2013/9/17 Ted Ross <tr...@redhat.com>:
>>
>>> I've been working on a sub-project within Apache Qpid called Qpid
>>> Dispatch
>>> Router. I'd like to invite use, participation, feedback, criticism, etc.
>>>
>>> There are a couple of basic introductory points to be made:
>>>
>>> * Dispatch Router is built on top of the Qpid Proton engine and driver
>>> APIs (The C implementations thereof).
>>> * A router is not a broker. The idea of a message router was born
>>> from the awkwardness of trying to build scaled-up messaging networks
>>> out of brokers.
>>> * A network built from routers provides interconnect between brokers,
>>> between clients and brokers, or between clients and clients (i.e.
>>> point-to-point non-brokered).
>>> * The message router brings together the two separate worlds of
>>> Messaging and Networking. Such a confluence was made possible by
>>> the AMQP 1.0 protocol. The vision is to provide a messaging
>>> interconnect that has all the advanced semantics of AMQP along with
>>> the scale, resiliency, and ease of deployment of an IP network.
>>>
>>> The code is in early stages of development and has not been through any
>>> kind
>>> of release. It builds only in Posix-based environments (Linux, etc.)
>>> and it
>>> only functions as a single stand-alone router at present (inter-router
>>> links
>>> are not yet fully implemented). The router can be used with both the
>>> Proton
>>> Messenger API and the Qpid Messaging Client APIs that support AMQP 1.0
>>> (and,
>>> in theory, with any AMQP 1.0 endpoint).
>>>
>>> The code can be found in the Subversion tree under
>>> "qpid/extras/dispatch".
>>>
>>> http://svn.apache.org/repos/**asf/qpid/trunk/qpid/extras/**dispatch<http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch>
>>>
>>> There is a draft web page for it here:
>>>
>>> http://qpid.apache.org/**components/dispatch-router/**index.html<http://qpid.apache.org/components/dispatch-router/index.html>
>>>
>>> Qpid Dispatch Router will provide two basic mechanisms for message
>>> routing.
>>> *Message Routing* forwards individual messages to their destination(s)
>>> based
>>> on the address in the message's "to" field. *Link Routing* propagates
>>> link-attaches across the network to the peer addressed in the link's
>>> "source" or "target" field. This is similar to creating a "virtual
>>> channel"
>>> across the network and allows the full semantics (transactions,
>>> flow-control, etc.) to be provided end-to-end (as though the
>>> participating
>>> endpoints were directly connected). Currently, only Message Routing is
>>> implemented.
>>>
>>> The following is a brief example of the router's use to illustrate how it
>>> works:
>>>
>>> [Refer to the README file for building instructions]
>>> [The router executable and Proton Messenger examples are assumed to be in
>>> the execution path]
>>>
>>> Run the following in separate terminal windows:
>>>
>>> $ router/dispatch-router -c <path-to-config-file>
>>> $ recv amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>
>>> $ recv amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>
>>> $ recv amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another>
>>> $ send -a amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>CONTENT
>>> $ send -a amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another>CONTENT
>>>
>>> The first line starts the router process (assumed to be configured to
>>> listen
>>> on port 5672). The "recv" examples create connections to the router and
>>> subscribe to two different address (two use the same address). The
>>> "send"
>>> examples create connections to the router and send messages to their
>>> respective addresses.
>>>
>>> If everything works, the first sent message will be received by the first
>>> two receivers and the second sent message will be received only by the
>>> third
>>> receiver.
>>>
>>> Regards,
>>>
>>> -Ted
>>>
>>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Introducing Qpid Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
Load-balanced fan-out is not currently implemented but is something that
I consider a key feature. I'd be interested to hear if you have
specific requirements for how it works.
One interesting request I've heard is to be able to establish groups of
consumers for a "topic". A message will be delivered to one consumer
within each group. In other words, messages are broadcast to all groups
but are load-balanced within each group.
-Ted
On 09/25/2013 03:48 AM, Mitsuru Oka wrote:
> Hello, I'm new to Proton and Dispatch router.
>
> I'd like to know if the Dispatch Router support more complex patterns
> such as pub-sub. Especially, whether load balanced routing to
> subscribe node is implemented or not is my interesting point.
>
> Thanks,
> Mitsuru Oka
>
>
> 2013/9/17 Ted Ross <tr...@redhat.com>:
>> I've been working on a sub-project within Apache Qpid called Qpid Dispatch
>> Router. I'd like to invite use, participation, feedback, criticism, etc.
>>
>> There are a couple of basic introductory points to be made:
>>
>> * Dispatch Router is built on top of the Qpid Proton engine and driver
>> APIs (The C implementations thereof).
>> * A router is not a broker. The idea of a message router was born
>> from the awkwardness of trying to build scaled-up messaging networks
>> out of brokers.
>> * A network built from routers provides interconnect between brokers,
>> between clients and brokers, or between clients and clients (i.e.
>> point-to-point non-brokered).
>> * The message router brings together the two separate worlds of
>> Messaging and Networking. Such a confluence was made possible by
>> the AMQP 1.0 protocol. The vision is to provide a messaging
>> interconnect that has all the advanced semantics of AMQP along with
>> the scale, resiliency, and ease of deployment of an IP network.
>>
>> The code is in early stages of development and has not been through any kind
>> of release. It builds only in Posix-based environments (Linux, etc.) and it
>> only functions as a single stand-alone router at present (inter-router links
>> are not yet fully implemented). The router can be used with both the Proton
>> Messenger API and the Qpid Messaging Client APIs that support AMQP 1.0 (and,
>> in theory, with any AMQP 1.0 endpoint).
>>
>> The code can be found in the Subversion tree under "qpid/extras/dispatch".
>>
>> http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch
>>
>> There is a draft web page for it here:
>>
>> http://qpid.apache.org/components/dispatch-router/index.html
>>
>> Qpid Dispatch Router will provide two basic mechanisms for message routing.
>> *Message Routing* forwards individual messages to their destination(s) based
>> on the address in the message's "to" field. *Link Routing* propagates
>> link-attaches across the network to the peer addressed in the link's
>> "source" or "target" field. This is similar to creating a "virtual channel"
>> across the network and allows the full semantics (transactions,
>> flow-control, etc.) to be provided end-to-end (as though the participating
>> endpoints were directly connected). Currently, only Message Routing is
>> implemented.
>>
>> The following is a brief example of the router's use to illustrate how it
>> works:
>>
>> [Refer to the README file for building instructions]
>> [The router executable and Proton Messenger examples are assumed to be in
>> the execution path]
>>
>> Run the following in separate terminal windows:
>>
>> $ router/dispatch-router -c <path-to-config-file>
>> $ recv amqp://0.0.0.0:5672/my_address/1
>> $ recv amqp://0.0.0.0:5672/my_address/1
>> $ recv amqp://0.0.0.0:5672/my_address/another
>> $ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
>> $ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
>>
>> The first line starts the router process (assumed to be configured to listen
>> on port 5672). The "recv" examples create connections to the router and
>> subscribe to two different address (two use the same address). The "send"
>> examples create connections to the router and send messages to their
>> respective addresses.
>>
>> If everything works, the first sent message will be received by the first
>> two receivers and the second sent message will be received only by the third
>> receiver.
>>
>> Regards,
>>
>> -Ted
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Introducing Qpid Dispatch Router
Posted by Mitsuru Oka <ok...@gmail.com>.
Hello, I'm new to Proton and Dispatch router.
I'd like to know if the Dispatch Router support more complex patterns
such as pub-sub. Especially, whether load balanced routing to
subscribe node is implemented or not is my interesting point.
Thanks,
Mitsuru Oka
2013/9/17 Ted Ross <tr...@redhat.com>:
> I've been working on a sub-project within Apache Qpid called Qpid Dispatch
> Router. I'd like to invite use, participation, feedback, criticism, etc.
>
> There are a couple of basic introductory points to be made:
>
> * Dispatch Router is built on top of the Qpid Proton engine and driver
> APIs (The C implementations thereof).
> * A router is not a broker. The idea of a message router was born
> from the awkwardness of trying to build scaled-up messaging networks
> out of brokers.
> * A network built from routers provides interconnect between brokers,
> between clients and brokers, or between clients and clients (i.e.
> point-to-point non-brokered).
> * The message router brings together the two separate worlds of
> Messaging and Networking. Such a confluence was made possible by
> the AMQP 1.0 protocol. The vision is to provide a messaging
> interconnect that has all the advanced semantics of AMQP along with
> the scale, resiliency, and ease of deployment of an IP network.
>
> The code is in early stages of development and has not been through any kind
> of release. It builds only in Posix-based environments (Linux, etc.) and it
> only functions as a single stand-alone router at present (inter-router links
> are not yet fully implemented). The router can be used with both the Proton
> Messenger API and the Qpid Messaging Client APIs that support AMQP 1.0 (and,
> in theory, with any AMQP 1.0 endpoint).
>
> The code can be found in the Subversion tree under "qpid/extras/dispatch".
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch
>
> There is a draft web page for it here:
>
> http://qpid.apache.org/components/dispatch-router/index.html
>
> Qpid Dispatch Router will provide two basic mechanisms for message routing.
> *Message Routing* forwards individual messages to their destination(s) based
> on the address in the message's "to" field. *Link Routing* propagates
> link-attaches across the network to the peer addressed in the link's
> "source" or "target" field. This is similar to creating a "virtual channel"
> across the network and allows the full semantics (transactions,
> flow-control, etc.) to be provided end-to-end (as though the participating
> endpoints were directly connected). Currently, only Message Routing is
> implemented.
>
> The following is a brief example of the router's use to illustrate how it
> works:
>
> [Refer to the README file for building instructions]
> [The router executable and Proton Messenger examples are assumed to be in
> the execution path]
>
> Run the following in separate terminal windows:
>
> $ router/dispatch-router -c <path-to-config-file>
> $ recv amqp://0.0.0.0:5672/my_address/1
> $ recv amqp://0.0.0.0:5672/my_address/1
> $ recv amqp://0.0.0.0:5672/my_address/another
> $ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
> $ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
>
> The first line starts the router process (assumed to be configured to listen
> on port 5672). The "recv" examples create connections to the router and
> subscribe to two different address (two use the same address). The "send"
> examples create connections to the router and send messages to their
> respective addresses.
>
> If everything works, the first sent message will be received by the first
> two receivers and the second sent message will be received only by the third
> receiver.
>
> Regards,
>
> -Ted
>
--
Mitsuru Oka
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org