Re: QPID JMS example cannot connect to the broker
On 12/23/2015 11:52 AM, Stein Wang wrote: After multiple trials, I still didn't get the amqp.so module. I had to install another virtual machine to build the QPID broker from scratch again. This time, I was lucky. I got the amqp.so module, and the JMS example finally said Hello. I don't understand why there is difference between the results of the two installation processes as I was acting exactly the same procedures. I'd like to learn it if someone knows the reason. I don't understand it either. The only criteria I can think of that affects whether amqp.so is built or not is whether the proton library could be found by cmake. In your case it reported it did find it. If you want to dig deeper perhaps we could compare the console output of a build that compiled amqp.so and one that did not(?) Thanks again for those who have helped me, and sorry for bothering with this entry-level question. No need to apologies, its a fair question, just one that I'm unable to answer at present, sorry! - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Failed to compile PHP bindings
On 12/26/2015 08:02 PM, Gintautas Miselis wrote: Hi, I have tried to compile PHP bindings, but no matter what I did they weren't compiled. I used this Dockerfile: FROM centos:6.7 RUN yum install -y php-cli php-common php-devel gcc cmake libuuid-devel openssl-devel tar wget && yum clean all Do you have swig installed by default? That is required for all the swig based bindings. RUN wget http://archive.apache.org/dist/qpid/proton/0.11.0/qpid-proton-0.11.0.tar.gz RUN mkdir -p qpid-proton/build && tar xzf qpid-proton-0.11.0.tar.gz -C /qpid-proton --strip-components=1 WORKDIR qpid-proton/build RUN cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DSYSINSTALL_BINDINGS=ON -DSYSINSTALL_PHP=ON -DBUILD_JAVA=OFF && make all && make install CMD ["/bin/bash"] php-config returns that --extension-dir is /usr/lib64/php/modules , so I expected to see proton.so file there. To get more information, I deleted content of the build directory and saved all output to files: rm -rf * cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DSYSINSTALL_BINDINGS=ON -DSYSINSTALL_PHP=ON -DBUILD_JAVA=OFF > cmake_output make all > make_all_output make install > make_install_output What have I missed? Thanks, Gintautas Miselis - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector
On 12/22/2015 08:43 PM, Olivier Mallassi wrote:
Looking at the qpid.filter definition, it looks like I can use a rich
grammar (AND, OR, LIKE?). Is this define somewhere?
It is the JMS selector syntax, as defined in the JMS spec (3.8.1 in
https://docs.oracle.com/cd/E19957-01/816-5904-10/816-5904-10.pdf)
Regarding the --argument, I was looking at the python source (
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/py/qpid-config)
but cannot find anything.
Around line 246 (or so, depending on exact version):
group3.add_option("--argument", dest="extra_arguments", action="append",
default=[],
metavar="", help="Specify a key-value pair to add
to queue arguments")
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: [C++ Broker][HA Queue Replication]
Again, thank you for all these details. In my case, I think I would prefer the federation option because I am fine with the fact the broker can "queue" and store messages backlog. Yet, let me think about this ;) Your remark regarding the unreliable side is interesting. In fact, I was thinking about using distributed (not federated) brokers, behind a couple of dispatch routers (and implement distributed queues) but I may not even need brokers. maybe a "dispatch router" acting as a relay would work perfectly! On Wed, Dec 30, 2015 at 7:09 PM, aconway wrote: > On Fri, 2015-12-18 at 09:24 +0100, Olivier Mallassi wrote: > > Hi all > > > > Gordon, thx. > > > > Regarding your last question "What are you aiming to achieve with the > > federation? Is it scaling beyond the capacity of a single broker?" I > > would > > say, "at term, yes" > > > > In fact, I have two main use-cases. > > 1/ the first one must be reliable. In that case, persistence and > > clustering > > should be used. But it must also be able to scale. Federation gives > > me a > > way to scale the publisher side by sending events in any brokers > > (round-robin load balancing) and behind the scene, the messages will > > end up > > in the right queue on the right broker (based on the bindings / > > routing > > key). > > It should be ok if routing keys are filtering events enough. > > You should be able to do this with dispatch to a HA cluster also. I'm > very interested in making sure dispatch works well in a HA environment > so let me know of any issues you come across. > > > > > 2/ the second one is unreliable but "low latency", must scale beyond > > broker > > capacity (almost sure), and HA. So you can loose message but the > > distribution chain must stay up and continue broadcasting incoming > > events. > > In that case, I do not want clustering (cause I do not want to pay > > the > > price of replication), but the dispatch router can help me because it > > gives > > me distributed queues. (I agree it will help me with security/proxies > > etc...) > > > > What are your thoughts on this? > > > On my side, clearly, the NFR (& figures) need to be clarified and > > more perf > > tests will be done. > > I am yet figuring out how to play with the 4 dimensions (persistence, > > clustering, federation, dispatch router) to build these channels, the > > simplest way possible. > > > > Dispatch: can help with scale, it does connection concentration and > (very limited) buffering so you can funnel large numbers of clients to > a single broker. The limited buffering can be considered a feature: > clients trying to send to an overloaded broker via dispatch will > experience flow-control back-pressure and slow down their sending till > the broker acks messages. > > Federation: a lot like dispatch in that you can set up flexible > mapping/routing rules. The big difference is a federated broker *does* > take responsibility for messages and can be a persistent and/or HA > "buffer" on the way to the final destination. > > The dispatch/federation trade off is: do you want your clients to be > forced to slow down when the "real" back-end is overloaded and wait > till it can handle more data, or do you want long "fire and forget" > buffers so clients can drop messages and move on even if the system is > busy? Buffers can help you get better throughput over short load spikes > but sustained overload will cause growing queues, growing latency and > generally bigger trouble before your clients start to back off. > > > For your summary my "gut reaction" would be to try dispatch to a > cluster or group of clusters initially for the reliable part. There is > a "distributed queue" test in the dispatch codebase that shows how you > can implement a "single queue" (from the sender and subscriber > perspective) as a set of queues on separate brokers - each of which > could be a cluster. I would add federation only if you have a need for > the kind of buffering I mention above, otherwise the dispatch topology > and horizontally adding clusters should cover a lot of scaling issues. > > For the unreliable side I would guess you could use dispatch alone - if > it is ok to lose messages if nobody is listening, then that is exactly > the default behavior for dispatch. > > Also the advantage of a dispatch backbone is you can change your choice > of broker without any effect on the clients. Only the broker > configuration would be different. > > > > > Cheers . > > > > > > > > > > > > > > On Wed, Dec 16, 2015 at 1:02 PM, Gordon Sim wrote: > > > > > On 12/15/2015 04:40 PM, Olivier Mallassi wrote: > > > > > > > Hi all > > > > > > > > I am still digging into the qpid technologies in order to better > > > > understand > > > > how all the pieces can be tied together. > > > > switching to the C++ broker implementation, I am trying to > > > > understand how > > > > HA cluster and federation can work together and your feedback > > > > would be > > > > appreciated. > > > > > > > > AFAIU, if
Re: [C++/Java Broker] [Transactions]
On 12/30/2015 06:37 PM, aconway wrote: On Wed, 2015-12-30 at 10:22 +0100, Olivier Mallassi wrote: Hi all again, my apologies for all these questions. I am trying to clarify my understanding around transactions support within qpid and here is my current understanding (based on documentation & JIRA). I have to say I did not test anything yet. Here's what I know: * qpidd C++ without HA: persistence (linearstore), TX, DTX. Though DTX is only supported over AMQP 0-10 at present. As Rob notes, AMQP 1.0 does not fully define how distributed transactions are supposed to work. * qpidd C++ with HA: persistence, limited TX, no DTX * dispatch link routing: will forward TX/DTX (I think, not tested) I'd be quite surprised if that works, unless there has been specific code added to allow it. The transaction context is sent as a special delivery state on the transfer or disposition and the way this is exposed in proton would require explicit handling to copy the data object associated with a delivery. From a quick grep of the dispatch code I don't see any reference to the relevant proton method (pn_disposition_data). * dispatch message routing: no TX/DTX [...] I believe dispatch *could* support at least some of the AMQP 1.0 TX and DTX modes even with message routing, we just haven't gotten there yet. For local transactions, any transfer or disposition related to the transaction needs to be routed to the same process, over the same connection[1], as that to which the transaction controller link is routed. [1] If the multi-ssns-per-txn capability is not supported by the process in question, the same session would have to be used. If the multi-txns-per-ssn capability was not supported then you would need a unique session for every distinct transaction. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
