RE: Documentaiton/clarification of heartbeat for broker
Thanks Gordon. Just to clarify default behaviour - for Java clients the default is 120s but for C++/Python clients the heartbeating is off and must be explicitly set? In other words, C++/Python clients that are dead (OS crash, network problems, client is hung) will be never removed from broker list of connected clients and will be included in max-connections (default 500) count? Thank you, Jan -Original Message- From: Gordon Sim [mailto:gordon.r@gmail.com] Sent: Tuesday, April 09, 2013 7:37 PM To: users@qpid.apache.org Subject: Re: Documentaiton/clarification of heartbeat for broker On 9 April 2013 15:28, Jan Bares jan.ba...@wood.cz wrote: I cannot find any documentation about how C++ broker detects dead clients. In client I can set heartbeat/idle_timeout - this will allow client to detect dead broker but I have not found any documentation how broker can detect dead clients. It even seems like broker doesn't use TCP_KEEPALIVE. Can anyone help me? The broker will use heartbeats for those connections where the client negotiates a non-zero interval for them. It doesn't use TCP_KEEPALIVE. DISCLAIMER WOOD Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.comhttp://www.wood.com/ under section Corporate Governance. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD Co. investment research opinions. This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [c++] Status of the AMQP 1.0 work
Hi Gordon,
Comments inline below.
Frase
On 09/04/13 19:07, Gordon Sim wrote:
On 6 April 2013 10:40, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
The x-bindings property is not currently supported for AMQP 1.0 in
nodes or links. This has really been a question of priorities rather
than ruling out any mapping. Though I don't think a generic binding
solution is appropriate for the 1.0 implementation, I'm eager to here
of use cases that would be affected here and see how best to address
them.
I use the headers exchange almost
exclusively in my operational system and my Addresses are of the form:
string address = testqueue; {create: receiver, node: {x-declare:
{arguments: {'qpid.policy_type': ring, 'qpid.max_size': 5}},
x-bindings: [{exchange: 'amq.match', queue: 'testqueue', key: 'data1',
arguments: {x-match: all, data-service: amqp-delivery, item-owner:
fadams}}]}};
Does each consumer create its own queue?
Sort of. Each logical consumer does, but a logical consumer may
comprise several physical nodes, they all use the same queue which
allows distribution of messages across the physical nodes giving the
ability to scale out quite easily.
I actually think this will be both
simpler and more powerful over 1.0 as the plan is to allow you to subscribe
to an exchange (which you can already do) using a selector.
Subscribing to an exchange is a term that makes me shudder from past
experience.
I'll try to explain, my system is perhaps a little unusual. I've got a
pretty large federated topology with lots of *real time* C++ producers
at one end of the topology and something of a mixed economy of mainly
Java and C++ (and a few Python) consumers mostly at the right hand
side having passed through some intermediate data consolidating
brokers. I've also got a few higher rate consumers subscribing directly
off the intermediate brokers. The mean message size tends to be
reasonably large, something like 50K but the tails are long and some
messages might be tens of MB.
Hopefully you noticed what I had in the x-declare of the example
Address. I'm using circular queues for a reason - high rate real time
producer, and we generally actually use 2GB queues to give moderate
elastic buffering given data rates and message size.
I've got nothing against the logical subscribing to an exchange
pattern and it is pretty common to see addresses simply expressing the
topic, but as you are aware under the hood this creates an autodelete,
exclusive, reject policy, default size queue!! I can't live with any of
those characteristics let alone all of them :-)
Indeed when I said it makes me shudder I'm actually thinking of our past
federation experiences, as you know static and dynamic routes are more
explicitly described as static and dynamic /exchange/ routes, because
they logically allow exchanges to be connected together. This is
conceptually very much like one exchange subscribing to another
exchange, but again they transparently create a queue almost completely
unsuitable for my purpose :-( We've had to use queue routes simply
because I can control the queue config. You wouldn't believe how fast
default size reject queues cause links to blow if one of my consumers
misbehaves, which clearly results in total data loss to all my consumers
not just the naughty one - not ideal.
I'd have *really* liked to be able to combine the rather elegant dynamic
binding propagation of dynamic routes with the ability to specify the
configuration of the queue/buffering used by the link with a great deal
more precision than the defaults.
Hopefully that background give some insight into my subscribing to an
exchange nerves :-/
Beyond that again if you notice from the example Address I use the
headers exchange pretty much universally. To be fair my architecture is
pretty much a publish/subscribe architecture and in the early days I
started with topics, but to be honest the largely static data model
and fairly inflexible wild-carding caused us to move to the headers
exchange pretty quickly. It's a lot easier to add new data types for
subscribing to with the headers exchange.
It hadn't escaped my notice that the bindings stanza was x-bindings
but as far as I've been able to work out that's the only way to create
bindings between the headers exchange and a named queue, indeed I
thought that x-bindings was the only way to create bindings between say
a user created topic exchange and a queue, though I may be wrong there.
If you can suggest how to say subscribe to a headers exchange without
using x-bindings that'd be neat, it'll be something I've totally missed.
Re using a selector I have to say that I'm definitely a big fan of
message selectors. It's worth pointing a few things out though. I
suspect that had message selectors been available when I started out
with my system I might well have used the topic exchange (with a named
queue!) plus message selectors. I've used
Re: [c++] Status of the AMQP 1.0 work
On 10 April 2013 13:38, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: Hi Gordon, Comments inline below. Frase On 09/04/13 19:07, Gordon Sim wrote: On 6 April 2013 10:40, Fraser Adams fraser.ad...@blueyonder.co.uk** wrote: [.. snip ..] Re using a selector I have to say that I'm definitely a big fan of message selectors. It's worth pointing a few things out though. I suspect that had message selectors been available when I started out with my system I might well have used the topic exchange (with a named queue!) plus message selectors. I've used JMS a lot in the past and that's at pattern that worked well and was very flexible, however as I said earlier the topic exchange on its own didn't cut the mustard for my needs so my producers describe their data purely by means of properties/headers. I guess you know this already but message selectors tend to behave as filters, so as I understand it messages would pass from exchange to queue and the selector would apply a filter to what gets passed off the queue to a consumer. I guess that to my way of thinking selectors provide most benefit in the realm of fine grained filtering in that they allow quite sophisticated boolean expressions to be applied. Now in my scenario quite clearly message selectors will be a boon and offer some really useful fine grained control (I've wanted to be able to do not for ages - you might just about recall one of my very early posts on the headers exchange asking about a not operator). However I think that message selectors are best applied *in addition to* a subscription, without that loads of messages get delivered onto the queue which the consumer isn't interested in, which a) fills up the queue unnecessarily and b) overworks the message selector logic (which I suspect is more expensive than the exchange selection logic). In my case in particular producers deliver quite a diverse range of data at very high rate so filling up consumer queues unnecessarily would be pretty bad news. So in précis while I really like message selectors I'd want them *in addition to* headers bindings and good granularity of queue control (I don't ask for much). So, just for info, the Java Broker currently allows for selectors to be applied either at the consumer, or (for the Topic Exchange only, but this should be made universal) on the binding ... that is the selector becomes a further refinement of the binding preventing ingress of non-matching messages into the queue. Another point about selectors. As I say I'm excited about them, but they are a new feature in the C++ broker (should be in 0.22 is that correct?). Andrew has done some great work so far, but he has very much said that the initial priority is on features and not interoperability. I'm fine with that initially, but you will undoubtedly have gathered from many of my posts that I'm really keen on maximum interoperability and cohesion. I'd really like to see the C++ message selectors ultimately become completely interoperable with JMS Message selectors. I've got no problem with an x-selector heading in the Address string but I'm really meaning at an API level too. I'd like to see JMS message selectors from JMS Clients propagate to the C++ and Java brokers and I'd like to see qpid::messaging extended to allow a JMS style message selector string to by passed to the createReceiver() call on Session. Clearly it's early days for C++ broker message selectors, but if that strategy wasn't part of the roadmap I'd be pretty uncomfortable. +1 ... I think it's unfortunate that the current implementation doesn't seem to match the Java implementation (nor do I remember this choice being discussed on list). There is a definition of what a an AMQP 1.0 selector should look like and we should probably all try to converge on that, but in the meantime increasing commonality rather than disparity would be nice. The key then (if I understand the usecase) would be to ensure that the subscrption had the right lifecycle (i.e. you could reconnect to it without loss of messages while disconnected), Well the lifecycle aspects are certainly part of it, hopefully my comments above have explained the other aspects of the set of use cases that are fairly critical to me. One thing that's not clear from your write up is whether the x-bindings property you are talking about is in the messaging client, or whether it is the underlying x-bindings property that gets passed to the broker. I'm guessing the latter which would also affect AddressStrings created by JMS consumers and via QMF? (Although I use the C++ broker most of my consumers use JMS). It is in the messaging client. The x-bindings (and x-declare, x-subscribe), map directly to 0-10 commands. There is no analogous mechanism for *generic* binding operations in 1.0 - i.e. the ability to bind almost anything to anything, regardless of the node you are sending to or
Modularizing Qpid
Hi, everyone. We've recently been discussing the components of our project in a couple different contexts. This is a proposal to take the outcomes of those discussion and apply them to how Qpid is organized. Thanks for taking a look, Justin ## Related discussions - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html ## The problem For a long time, Qpid was in many respects treated as one thing, with one release cycle. Its parts were divided at the top level by language, not function. The division by language provides little incentive to factor out dependencies into clean interfaces, and it has tended to mean that developers often work in just one language silo. It has also meant that our source modules have only a weak correspondence to the user-focused release artifacts that we produce. With Proton, we've broken the mold, and the overall picture of Qpid is inconsistent and confusing, to the Qpid developers and users. ## The proposed approach - Qpid the project embraces a functional division of components - Each source component is self-contained and independent, with a focused purpose; among components, there are well defined dependencies - The source components should correspond closely to the pieces our users want to use independently; nonetheless, there would in some cases be multiple release artifacts from a component - Each component has its own set of branches, supporting independent releases - Each component should be neither too large nor too small; large enough to ease development and release management; small enough to represent a focused functional unit and to clarify dependencies - API components would in some cases also contain code shared by APIs and servers; the server would in that case depend on the API code base ## Proposed source components - Proton (this one already exists) - /qpid/proton/trunk/ - JMS - /qpid/jms/trunk/ - Depends on Proton - Java broker - /qpid/java-broker/trunk/ - Depends on JMS (?) - Messaging API - /qpid/messaging-api/trunk/ - Both the C++ (and bindings) and python implementations would move here - Depends on Proton - C++ broker - /qpid/cpp-broker/trunk/ - Depends on Messaging-API Note that this matches the download page of the new website pretty nicely. - http://people.apache.org/~jross/transom/head/download.html There's some debate about the right names for these things. Don't take my suggestions seriously. I just had to put something down to illustrate. If I had my druthers, we'd give the two brokers names that didn't include a programming language. ## First steps This change can't happen all at once. We propose to start with these: - Isolate JMS from the existing qpid/trunk/qpid tree - Isolate the Messaging API from the existing qpid/trunk/qpid tree If this is agreed, the idea is to bite off this much during the 0.24 cycle. ## Developer infrastructure This change calls for some work to support developers using multiple components in one development environment. This needs more investigation. ## JIRA instances We propose *not* to create new jira instances for each component. We can do that later on if necessary. For now we can overload the version field in the qpid jira instance to include a component name. ## A Qpid distribution of source component releases While this scheme supports independent releases of each source component, it doesn't rule out a Qpid-wide release. There may be reason for Qpid as a whole to share a release cadence and produce a new distribution of components each cycle. It would all be more flexible, however. A component might want to produce three revisions in the space of a standard Qpid-wide four-month cycle, or a component might produce no new revisions. To me the advantage of producing a periodic distribution is (a) coordinated testing and (b) a known distribution set for users to deploy together. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Modularizing Qpid
I'm +1 this... Obviously we need to understand better the amount of work to achieve the separation of the components... but if this were in place then we wouldn't be facing the sort of issues we are currently experiencing with the 0.22 release which would strongly benefit from not having the release cycles of all components tied together. -- Rob On 10 April 2013 15:55, Justin Ross jr...@apache.org wrote: Hi, everyone. We've recently been discussing the components of our project in a couple different contexts. This is a proposal to take the outcomes of those discussion and apply them to how Qpid is organized. Thanks for taking a look, Justin ## Related discussions - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html ## The problem For a long time, Qpid was in many respects treated as one thing, with one release cycle. Its parts were divided at the top level by language, not function. The division by language provides little incentive to factor out dependencies into clean interfaces, and it has tended to mean that developers often work in just one language silo. It has also meant that our source modules have only a weak correspondence to the user-focused release artifacts that we produce. With Proton, we've broken the mold, and the overall picture of Qpid is inconsistent and confusing, to the Qpid developers and users. ## The proposed approach - Qpid the project embraces a functional division of components - Each source component is self-contained and independent, with a focused purpose; among components, there are well defined dependencies - The source components should correspond closely to the pieces our users want to use independently; nonetheless, there would in some cases be multiple release artifacts from a component - Each component has its own set of branches, supporting independent releases - Each component should be neither too large nor too small; large enough to ease development and release management; small enough to represent a focused functional unit and to clarify dependencies - API components would in some cases also contain code shared by APIs and servers; the server would in that case depend on the API code base ## Proposed source components - Proton (this one already exists) - /qpid/proton/trunk/ - JMS - /qpid/jms/trunk/ - Depends on Proton - Java broker - /qpid/java-broker/trunk/ - Depends on JMS (?) - Messaging API - /qpid/messaging-api/trunk/ - Both the C++ (and bindings) and python implementations would move here - Depends on Proton - C++ broker - /qpid/cpp-broker/trunk/ - Depends on Messaging-API Note that this matches the download page of the new website pretty nicely. - http://people.apache.org/~jross/transom/head/download.html There's some debate about the right names for these things. Don't take my suggestions seriously. I just had to put something down to illustrate. If I had my druthers, we'd give the two brokers names that didn't include a programming language. ## First steps This change can't happen all at once. We propose to start with these: - Isolate JMS from the existing qpid/trunk/qpid tree - Isolate the Messaging API from the existing qpid/trunk/qpid tree If this is agreed, the idea is to bite off this much during the 0.24 cycle. ## Developer infrastructure This change calls for some work to support developers using multiple components in one development environment. This needs more investigation. ## JIRA instances We propose *not* to create new jira instances for each component. We can do that later on if necessary. For now we can overload the version field in the qpid jira instance to include a component name. ## A Qpid distribution of source component releases While this scheme supports independent releases of each source component, it doesn't rule out a Qpid-wide release. There may be reason for Qpid as a whole to share a release cadence and produce a new distribution of components each cycle. It would all be more flexible, however. A component might want to produce three revisions in the space of a standard Qpid-wide four-month cycle, or a component might produce no new revisions. To me the advantage of producing a periodic distribution is (a) coordinated testing and (b) a known distribution set for users to deploy together. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Maybe bug, maybe novice mistake, or maybe my python qpid library is too old.
Good catch Bill - this is a bug, and I've entered a JIRA for it:
https://issues.apache.org/jira/browse/QPID-4732
That said, I would urge you not to use the QPID connection directly. The API
doesn't explicitly expose this, and we probably will be moving the QMF client
to use the client messaging interface at some point (which will break what
you're doing).
Instead, you should create a separate connection to the broker using the Qpid
Messaging client API as described here:
http://qpid.apache.org/books/0.20/Programming-In-Apache-Qpid/html/index.html
-K
- Original Message -
From: Bill Freeman ke1g...@gmail.com
To: users users@qpid.apache.org
Sent: Tuesday, April 9, 2013 5:56:34 PM
Subject: Maybe bug, maybe novice mistake, or maybe my python qpid library is
too old.
In my qmf.console based app, I was trying to figure out how to piggy-back
my browsing of a queue
on the existing broker's connection, using
broker.conn.session('somename'), and while pdb was trying to print a stack
trace, the __str__ method of the qpid.connection.Connection instance got
called. This does (at line 225 in my copy):
return %s:%s % self.sock.getsockname()
Now, getsockname() returns:
('::1', 49845, 0, 0)
So it's no wonder that pdb gets a:
TypeError: not all arguments converted during string formatting
I'm guessing that the code was written before getsockname() became IPv6
aware?
Bill
--
-K
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: How to set ssl_keyfile and ssl_certfile for python tools (to c++ broker) from the command line?
Hi D James, I'm pretty sure the ssl options were added to qpid-config _after_ 0.18. I think they first appeared in the 0.20 release. Does qpid-config --help list them? -K - Original Message - From: djames dpgja...@gmail.com To: users@qpid.apache.org Sent: Tuesday, April 9, 2013 5:41:35 PM Subject: How to set ssl_keyfile and ssl_certfile for python tools (to c++ broker) from the command line? I have been trying to do this for a few days. My python is not very strong. I have been trying combinations and permutions of: qpid-config -b amqps://localhost , ssl_certfile=/path/to/certfile, ssl_keyfile=/path/to/keyfile --sasl-mechanism='EXTERNAL' I am currently using qpid 0.18. An example from someone that knows what they are doing would be very welcome. D James -- View this message in context: http://qpid.2158936.n2.nabble.com/How-to-set-ssl-keyfile-and-ssl-certfile-for-python-tools-to-c-broker-from-the-command-line-tp7591358.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Maybe bug, maybe novice mistake, or maybe my python qpid library is too old.
Ken,
On Wed, Apr 10, 2013 at 10:56 AM, Ken Giusti kgiu...@redhat.com wrote:
Good catch Bill - this is a bug, and I've entered a JIRA for it:
https://issues.apache.org/jira/browse/QPID-4732
That said, I would urge you not to use the QPID connection directly. The
API doesn't explicitly expose this, and we probably will be moving the QMF
client to use the client messaging interface at some point (which will
break what you're doing).
Instead, you should create a separate connection to the broker using the
Qpid Messaging client API as described here:
http://qpid.apache.org/books/0.20/Programming-In-Apache-Qpid/html/index.html
Yes, I have made it work with the Messaging API.
And although they both have objects called Connection and Session, I now
know that they are not the same. (I certainly haven't found any
documentation for the low level API.)
It just seems a shame to have to open a second connection to the broker.
As long as I have your attention, does ;{mode:browse} affect the need to
acknowledge messages?
Thanks, Bill
Re: Modularizing Qpid
+1 on this. Having the flexibility to have individual release cycles for each component will be huge advantage for us. However as Justin mentioned, we shouldn't rule out a Qpid wide release perhaps once a year or so. From a users perspective this is a great thing to have, bcos all the components bundled under that release will be guaranteed to work well together. Rajith On Wed, Apr 10, 2013 at 10:46 AM, Rob Godfrey rob.j.godf...@gmail.comwrote: I'm +1 this... Obviously we need to understand better the amount of work to achieve the separation of the components... but if this were in place then we wouldn't be facing the sort of issues we are currently experiencing with the 0.22 release which would strongly benefit from not having the release cycles of all components tied together. -- Rob On 10 April 2013 15:55, Justin Ross jr...@apache.org wrote: Hi, everyone. We've recently been discussing the components of our project in a couple different contexts. This is a proposal to take the outcomes of those discussion and apply them to how Qpid is organized. Thanks for taking a look, Justin ## Related discussions - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html ## The problem For a long time, Qpid was in many respects treated as one thing, with one release cycle. Its parts were divided at the top level by language, not function. The division by language provides little incentive to factor out dependencies into clean interfaces, and it has tended to mean that developers often work in just one language silo. It has also meant that our source modules have only a weak correspondence to the user-focused release artifacts that we produce. With Proton, we've broken the mold, and the overall picture of Qpid is inconsistent and confusing, to the Qpid developers and users. ## The proposed approach - Qpid the project embraces a functional division of components - Each source component is self-contained and independent, with a focused purpose; among components, there are well defined dependencies - The source components should correspond closely to the pieces our users want to use independently; nonetheless, there would in some cases be multiple release artifacts from a component - Each component has its own set of branches, supporting independent releases - Each component should be neither too large nor too small; large enough to ease development and release management; small enough to represent a focused functional unit and to clarify dependencies - API components would in some cases also contain code shared by APIs and servers; the server would in that case depend on the API code base ## Proposed source components - Proton (this one already exists) - /qpid/proton/trunk/ - JMS - /qpid/jms/trunk/ - Depends on Proton - Java broker - /qpid/java-broker/trunk/ - Depends on JMS (?) - Messaging API - /qpid/messaging-api/trunk/ - Both the C++ (and bindings) and python implementations would move here - Depends on Proton - C++ broker - /qpid/cpp-broker/trunk/ - Depends on Messaging-API Note that this matches the download page of the new website pretty nicely. - http://people.apache.org/~jross/transom/head/download.html There's some debate about the right names for these things. Don't take my suggestions seriously. I just had to put something down to illustrate. If I had my druthers, we'd give the two brokers names that didn't include a programming language. ## First steps This change can't happen all at once. We propose to start with these: - Isolate JMS from the existing qpid/trunk/qpid tree - Isolate the Messaging API from the existing qpid/trunk/qpid tree If this is agreed, the idea is to bite off this much during the 0.24 cycle. ## Developer infrastructure This change calls for some work to support developers using multiple components in one development environment. This needs more investigation. ## JIRA instances We propose *not* to create new jira instances for each component. We can do that later on if necessary. For now we can overload the version field in the qpid jira instance to include a component name. ## A Qpid distribution of source component releases While this scheme supports independent releases of each source component, it doesn't rule out a Qpid-wide release. There may be reason for Qpid as a whole to share a release cadence and produce a new distribution of components each cycle. It would all be more flexible, however. A component might want to produce three revisions in the space of a standard Qpid-wide four-month cycle, or a component might produce no new revisions.
Re: How to set ssl_keyfile and ssl_certfile for python tools (to c++ broker) from the command line?
Hi Ken, I don't know about the Qpid 0.18 release, but he might be using MRG-M 2.3 which reports it self as Qpid 0.18 and contains the SSL support in qpid-config. Regards Jakub On Wed, Apr 10, 2013 at 5:07 PM, Ken Giusti kgiu...@redhat.com wrote: Hi D James, I'm pretty sure the ssl options were added to qpid-config _after_ 0.18. I think they first appeared in the 0.20 release. Does qpid-config --help list them? -K - Original Message - From: djames dpgja...@gmail.com To: users@qpid.apache.org Sent: Tuesday, April 9, 2013 5:41:35 PM Subject: How to set ssl_keyfile and ssl_certfile for python tools (to c++ broker) from the command line? I have been trying to do this for a few days. My python is not very strong. I have been trying combinations and permutions of: qpid-config -b amqps://localhost , ssl_certfile=/path/to/certfile, ssl_keyfile=/path/to/keyfile --sasl-mechanism='EXTERNAL' I am currently using qpid 0.18. An example from someone that knows what they are doing would be very welcome. D James -- View this message in context: http://qpid.2158936.n2.nabble.com/How-to-set-ssl-keyfile-and-ssl-certfile-for-python-tools-to-c-broker-from-the-command-line-tp7591358.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Maybe bug, maybe novice mistake, or maybe my python qpid library is too old.
- Original Message -
From: Bill Freeman ke1g...@gmail.com
To: users users@qpid.apache.org
Sent: Wednesday, April 10, 2013 11:23:04 AM
Subject: Re: Maybe bug, maybe novice mistake, or maybe my python qpid library
is too old.
Ken,
snip
As long as I have your attention, does ;{mode:browse} affect the need to
acknowledge messages?
Thanks, Bill
Hi Bill -
Since you are not transferring ownership of the message, ack'ing each message
isn't strictly necessary.
However, I seem to recall that issuing an occasional ack could affect other
aspects of the consumer, like replenishment of prefetch credit, or something
else that may improve overall performance.
But I'm not the best person to ask - anyone else care to weigh in?
thanks,
--
-K
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Modularizing Qpid
On Wed, Apr 10, 2013 at 09:55:22AM -0400, Justin Ross wrote: Hi, everyone. We've recently been discussing the components of our project in a couple different contexts. This is a proposal to take the outcomes of those discussion and apply them to how Qpid is organized. +1 -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgprXkHaxemiW.pgp Description: PGP signature
Re: Modularizing Qpid
+1 from me as well. I think this would be a good improvement on the existing structure and benefit everyone by allowing for schedules more tailored to the specific components, and in turn enable us to better meet the needs of their users. We would need to investigate how some of the changes might best be achieved, and thus better understand how much effort is likely to be involved as Rob mentioned. I think it is at least somewhat likely it would be easier to do the JMS clients and the Java broker at the same time rather than separately for example, but we would need to examine the options to be sure. Robbie On 10 April 2013 15:46, Rob Godfrey rob.j.godf...@gmail.com wrote: I'm +1 this... Obviously we need to understand better the amount of work to achieve the separation of the components... but if this were in place then we wouldn't be facing the sort of issues we are currently experiencing with the 0.22 release which would strongly benefit from not having the release cycles of all components tied together. -- Rob On 10 April 2013 15:55, Justin Ross jr...@apache.org wrote: Hi, everyone. We've recently been discussing the components of our project in a couple different contexts. This is a proposal to take the outcomes of those discussion and apply them to how Qpid is organized. Thanks for taking a look, Justin ## Related discussions - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html ## The problem For a long time, Qpid was in many respects treated as one thing, with one release cycle. Its parts were divided at the top level by language, not function. The division by language provides little incentive to factor out dependencies into clean interfaces, and it has tended to mean that developers often work in just one language silo. It has also meant that our source modules have only a weak correspondence to the user-focused release artifacts that we produce. With Proton, we've broken the mold, and the overall picture of Qpid is inconsistent and confusing, to the Qpid developers and users. ## The proposed approach - Qpid the project embraces a functional division of components - Each source component is self-contained and independent, with a focused purpose; among components, there are well defined dependencies - The source components should correspond closely to the pieces our users want to use independently; nonetheless, there would in some cases be multiple release artifacts from a component - Each component has its own set of branches, supporting independent releases - Each component should be neither too large nor too small; large enough to ease development and release management; small enough to represent a focused functional unit and to clarify dependencies - API components would in some cases also contain code shared by APIs and servers; the server would in that case depend on the API code base ## Proposed source components - Proton (this one already exists) - /qpid/proton/trunk/ - JMS - /qpid/jms/trunk/ - Depends on Proton - Java broker - /qpid/java-broker/trunk/ - Depends on JMS (?) - Messaging API - /qpid/messaging-api/trunk/ - Both the C++ (and bindings) and python implementations would move here - Depends on Proton - C++ broker - /qpid/cpp-broker/trunk/ - Depends on Messaging-API Note that this matches the download page of the new website pretty nicely. - http://people.apache.org/~jross/transom/head/download.html There's some debate about the right names for these things. Don't take my suggestions seriously. I just had to put something down to illustrate. If I had my druthers, we'd give the two brokers names that didn't include a programming language. ## First steps This change can't happen all at once. We propose to start with these: - Isolate JMS from the existing qpid/trunk/qpid tree - Isolate the Messaging API from the existing qpid/trunk/qpid tree If this is agreed, the idea is to bite off this much during the 0.24 cycle. ## Developer infrastructure This change calls for some work to support developers using multiple components in one development environment. This needs more investigation. ## JIRA instances We propose *not* to create new jira instances for each component. We can do that later on if necessary. For now we can overload the version field in the qpid jira instance to include a component name. ## A Qpid distribution of source component releases While this scheme supports independent releases of each source component, it doesn't rule out a Qpid-wide release. There may be reason for Qpid as a whole to share a release cadence and produce a new
Re: Maybe bug, maybe novice mistake, or maybe my python qpid library is too old.
On Wed, Apr 10, 2013 at 12:42 PM, Ken Giusti kgiu...@redhat.com wrote:
- Original Message -
From: Bill Freeman ke1g...@gmail.com
To: users users@qpid.apache.org
Sent: Wednesday, April 10, 2013 11:23:04 AM
Subject: Re: Maybe bug, maybe novice mistake, or maybe my python qpid
library is too old.
Ken,
snip
As long as I have your attention, does ;{mode:browse} affect the need to
acknowledge messages?
Thanks, Bill
Hi Bill -
Since you are not transferring ownership of the message, ack'ing each
message isn't strictly necessary.
However, I seem to recall that issuing an occasional ack could affect
other aspects of the consumer, like replenishment of prefetch credit, or
something else that may improve overall performance.
But I'm not the best person to ask - anyone else care to weigh in?
thanks,
I thought I saw somewhere in the code that there is a list of unacked
messages in the python client library, and things go there without any kind
of check, that I could see, as to whether they were a browse. So it might
be that the broker doesn't need it, but that it consumes memory in the
client. Of course I can't remember whether I saw that in the low level or
the messaging layer code.
If the broker doesn't need it, it's a pity to waste the bandwidth sending
the ack, assuming that client doesn't figure out that the ack isn't needed,
and quash it.
Bill
Re: Modularizing Qpid
From a user point of view ... if the client libraries have independent releases, it might be more clear to many people that they do not need to use exactly the same version of the client library as is the broker version. That seems to be quite popular believe among the people connecting to our brokers. I hope the new website will help a bit with this as well. Similarly, it might also clear a few misunderstandings that the Java broker and the C++ broker are fully identical in terms of features / functionality, just written in different language. Regards Jakub On Wed, Apr 10, 2013 at 3:55 PM, Justin Ross jr...@apache.org wrote: Hi, everyone. We've recently been discussing the components of our project in a couple different contexts. This is a proposal to take the outcomes of those discussion and apply them to how Qpid is organized. Thanks for taking a look, Justin ## Related discussions - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html ## The problem For a long time, Qpid was in many respects treated as one thing, with one release cycle. Its parts were divided at the top level by language, not function. The division by language provides little incentive to factor out dependencies into clean interfaces, and it has tended to mean that developers often work in just one language silo. It has also meant that our source modules have only a weak correspondence to the user-focused release artifacts that we produce. With Proton, we've broken the mold, and the overall picture of Qpid is inconsistent and confusing, to the Qpid developers and users. ## The proposed approach - Qpid the project embraces a functional division of components - Each source component is self-contained and independent, with a focused purpose; among components, there are well defined dependencies - The source components should correspond closely to the pieces our users want to use independently; nonetheless, there would in some cases be multiple release artifacts from a component - Each component has its own set of branches, supporting independent releases - Each component should be neither too large nor too small; large enough to ease development and release management; small enough to represent a focused functional unit and to clarify dependencies - API components would in some cases also contain code shared by APIs and servers; the server would in that case depend on the API code base ## Proposed source components - Proton (this one already exists) - /qpid/proton/trunk/ - JMS - /qpid/jms/trunk/ - Depends on Proton - Java broker - /qpid/java-broker/trunk/ - Depends on JMS (?) - Messaging API - /qpid/messaging-api/trunk/ - Both the C++ (and bindings) and python implementations would move here - Depends on Proton - C++ broker - /qpid/cpp-broker/trunk/ - Depends on Messaging-API Note that this matches the download page of the new website pretty nicely. - http://people.apache.org/~jross/transom/head/download.html There's some debate about the right names for these things. Don't take my suggestions seriously. I just had to put something down to illustrate. If I had my druthers, we'd give the two brokers names that didn't include a programming language. ## First steps This change can't happen all at once. We propose to start with these: - Isolate JMS from the existing qpid/trunk/qpid tree - Isolate the Messaging API from the existing qpid/trunk/qpid tree If this is agreed, the idea is to bite off this much during the 0.24 cycle. ## Developer infrastructure This change calls for some work to support developers using multiple components in one development environment. This needs more investigation. ## JIRA instances We propose *not* to create new jira instances for each component. We can do that later on if necessary. For now we can overload the version field in the qpid jira instance to include a component name. ## A Qpid distribution of source component releases While this scheme supports independent releases of each source component, it doesn't rule out a Qpid-wide release. There may be reason for Qpid as a whole to share a release cadence and produce a new distribution of components each cycle. It would all be more flexible, however. A component might want to produce three revisions in the space of a standard Qpid-wide four-month cycle, or a component might produce no new revisions. To me the advantage of producing a periodic distribution is (a) coordinated testing and (b) a known distribution set for users to deploy together. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
