On 09/02/2010 03:03 AM, tingliang wu wrote:
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.
The last sentence sounds like what you want may be the dynamic routing. However that does not balance the load between the downstream servers - they would each get copies of messages as dictated by their local bindings.
There is as yet no linking of flow over queue based routes to bindings on the remote exchange.
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.
No, there is as yet no flow control between brokers. However acknowledged transfer is possible between brokers.
3. And when i bind a queue to the fed_queue.direct, it will lose the historied messages, will IVE help?
I doubt it, but would need more context for your use case.
4. Can the client0 communicates with broker0 directly, not bypass the localhost socket?
If I understand the question correctly, no, not yet. At present you have to use tcp (or rdma) to communicate with the broker even if it is running on the same box.
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.
At present there isn't really any support for having the broker in-process. The broker APIs are subject to modification between releases.
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?
I don't quite understand the issue you are describing here. Could you list the steps in more detail, and state the expected behaviour and the observed behaviour?
6. Is there any difference between the Messaging APIs, the Client APIs and the Framing APIs?
The messaging API is the one we will be encouraging for ongoing use as it is more future proof and offers a better interface behind which to include richer functionality. Only an early preview of this was available in 0.6 however, so the first proper release will be the next one.
The client and framing APIs are tied more directly to a particular protocol version. The messaging API is intended as a replacement, though the older API will continue to be supported (though not necessarily developed further).
How can i use the file messages as descriped in amqp-10 to transfer files?
No, that isn't supported.
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?
Yes, but at present a message is loaded in to memory in its entirety before being sent out, so the memory available limits the maximum message size. If you want to transfer larger files than that you would need to break them up and re-assemble them.
--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
