2010/9/3 Gordon Sim <[email protected]> > 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.
I want to use the queue route's load balance feature in brokers federation( 10001 <= 5672,10002,10003 and fed_queue => fed_queue.direct): ./qpid-config -a localhost:5672 add exchange direct fed_queue.direct --durable ./qpid-config -a localhost:10002 add exchange direct fed_queue.direct --durable ./qpid-config -a localhost:10003 add exchange direct fed_queue.direct --durable ./qpid-config -a localhost:10001 add queue fed_queue --durable ./qpid-route -v queue add localhost:5672 localhost:10001 fed_queue.direct file-server ./qpid-route -v queue add localhost:10002 localhost:10001 fed_queue.direct file-server ./qpid-route -v queue add localhost:10003 localhost:10001 fed_queue.direct file-server So, as decsribed above in Question 1, the 10001 broker will always transfer messages to the other three brokers' fed_queue.direct, regardless whether or not the destination brokers(5672,10002,10003) have bindings to their fed_queue.direct. When there are not bindings to fed_queue.direct, the transfered messages will lose! I doubt that whether IVE fed_queue.direct will help to solve this problem? Or will the qpid-0.7 solve this problem? PS: It seems that there is little details about the behaviours between brokers in federation! Would you please send me some other related documents except https://cwiki.apache.org/qpid/using-broker-federation.html ? > > > 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? > > Steps: 1) I build the bi-direction dynamic durable routes as follows( so the clients can use point-to-point communication with a unique binding key to fed.direct ): ./qpid-route -v link add localhost:5672 localhost:10001 --durable ./qpid-route -v link add localhost:10001 localhost:5672 --durable ./qpid-config -a localhost:5672 add exchange direct fed.direct --durable ./qpid-config -a localhost:10001 add exchange direct fed.direct --durable ./qpid-route dynamic add localhost:5672 localhost:10001 fed.direct --durable ./qpid-route dynamic add localhost:10001 localhost:5672 fed.direct --durable So now i buid bi-directon routes: 5672<=>10001 2)Then i stop broker 10001: ./qpidd -q -p 10001 3)When i restart broker 10001: ./qpidd --auth no -p 10001 -d --no-data-dir Observed behaviour: Only one direction route is rebuit: 5672=>10001 Expected behaviour: The bi-direction dynamic durable routes rebuid again: 5672<=>10001 The route is not durable!!! Only the initialting broker can rebuid its exchange route. Will qpid surpport this feature in 0.7 version??? > > 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] > >
