Hi, when I use the Apache Qpid brokers
federation, many problems come to me!

The questions are described below. In case of ruin the federation diagram, I
also have an attachment in the email.

It will be very nice of you to pay an attention to my questions! Looking
forward to your professional solutions!

Thanks!

federation:
I need to build brokers federation (queue route) while the client and the
broker are at the same machine.I use queue route script tools
(qpid-route,qpid-config) to build the federation as follows( use the traffic
balance characteristic):

 |---------------|
 |     client0 |
 |---------------| machine0
 |    broker0 |
 |   fed_queue |
 |---------------|
  |\
        |  \  ...balance the traffic
       |     \
       V      V
|---------------| |---------------|
|fed_queue.direct |fed_queue.direct|
|    broker1 | |     broker2 |
|---------------| |---------------| ...
|   client1 | |     client2 |
|---------------| |---------------|
 machine1  machine2


Questons:
1.
It seems that the fed_queue will continuelly sends messages to the
fed_queue.directs regardless whether or not the destination brokers have
bindings to the fed_queue.directs,  why ? As i need that if there is not
bindings to the fed_queue.direct, the messages will not be sent to this
fed_queue.direct, it will be sent to the other fed_queue.direct or stored in
the fed_queue queue.
2.
Can the brokers transfer messages reliably? That is to say, can i assume
that the brokers will not overflow when we have flow-control between the
clients and their brokers.
3.
And when i bind a queue to the fed_queue.direct, it will lose the historied
messages, will IVE help?
4.
Can the client0 communicates with broker0 directly, not bypass the localhost
socket?
When i transfer binary datas, i have to assign it to a std::string object
str(this result in a copy of it), and str will be copied internally when
call message.setData(str) funtions. it seems uneffeciently to have duplicate
copy especially when the client has thousands of or even millions of
messages to be sent.
Is there any binary interface to avoid this problem?
It is best to store the messages directly into the brokers' fed_queue, can i
attain it???  This can distribute the brokers into special clients that play
a server role collecting request messages from their clients and forward it
to the real server.

5.
I build(using the qpid-route and qpid-config tools) a bi-directional duralbe
link and dynamic route between two brokers, when one broker restarts, only
one direction route and link are rebuilt, why? Is there any way to re-start
the bi-directional routes without runnig the qpid-route scripts again?
6.
Is there any difference between the Messaging APIs, the Client APIs and the
Framing APIs?
How can i use the file messages as descriped in amqp-10 to transfer files?
How the file disassembled and assembled in the brokers when transfered
across the fedeartion brokers?  Can i use the Client::Message to transfer
large files with no attention to disassemble and assemble the file?
federation:
I need to build brokers federation (queue route) while the client and the 
broker are at the same machine.I use queue route script tools 
(qpid-route,qpid-config) to build the federation as follows( use the traffic 
balance characteristic):

        |---------------|
        |     client0   |
        |---------------| machine0
        |    broker0    |
        |   fed_queue   |
        |---------------|
                |\
               |  \  ...balance the traffic
              |     \
              V      V
|---------------|       |---------------|
|fed_queue.direct       |fed_queue.direct
|    broker1    |       |     broker2   |
|---------------|       |---------------| ...
|   client1     |       |     client2   |
|---------------|       |---------------|
        machine1                machine2


Questons:
1.
It seems that the fed_queue will continuelly sends messages to the 
fed_queue.directs regardless whether or not the destination brokers have 
bindings to the fed_queue.directs,  why ? As i need that if there is not 
bindings to the fed_queue.direct, the messages will not be sent to this 
fed_queue.direct, it will be sent to the other fed_queue.direct or stored in 
the fed_queue queue. 
2.
Can the brokers transfer messages reliably? That is to say, can i assume that 
the brokers will not overflow when we have flow-control between the clients and 
their brokers.
3.
And when i bind a queue to the fed_queue.direct, it will lose the historied 
messages, will IVE help?
4.
Can the client0 communicates with broker0 directly, not bypass the localhost 
socket? 
When i transfer binary datas, i have to assign it to a std::string object  
str(this result in a copy of it), and str will be copied internally when call 
message.setData(str) funtions. it seems uneffeciently to have duplicate copy 
especially when the client has thousands of or even millions of messages to be 
sent. 
Is there any binary interface to avoid this problem? 
It is best to store the messages directly into the brokers' fed_queue, can i 
attain it???  This can distribute the brokers into special clients that play a 
server role collecting request messages from their clients and forward it to 
the real server.

5.
I build(using the qpid-route and qpid-config tools) a bi-directional duralbe 
link and dynamic route between two brokers, when one broker restarts, only one 
direction route and link are rebuilt, why? Is there any way to re-start the 
bi-directional routes without runnig the qpid-route scripts again?
6.
Is there any difference between the Messaging APIs, the Client APIs and the 
Framing APIs? 
How can i use the file messages as descriped in amqp-10 to transfer files? 
How the file disassembled and assembled in the brokers when transfered across 
the fedeartion brokers?  Can i use the Client::Message to transfer large files 
with no attention to disassemble and assemble the file?






  
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to