[jira] [Created] (QPID-4161) Move the build system to CMake
Darryl L. Pierce created QPID-4161: -- Summary: Move the build system to CMake Key: QPID-4161 URL: https://issues.apache.org/jira/browse/QPID-4161 Project: Qpid Issue Type: Improvement Components: Build Tools Reporter: Darryl L. Pierce The Cmake system needs to be updated so that it can replace the existing autotools system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proton: motivation and strategy
Wow that was some thread! Sorry I'm not going to respond to any specific part but the overall themes. It seems there are two higher level threads: 1. What about proton and where is it's future? 2. What about legacy Qpid and how does proton effect it? And that is really how it should be. The questions we should be asking to figure out the answers to the above are: Is AMQP more important than "legacy" Qpid? Is proton about AMQP 1.0 or about "legacy" Qpid? (migrating Qpid to AMQP 1.0) AMQP and it's broad adoption is the most important. Proton is all about AMQP 1.0 and therefore it is critical to the expansion and adoption of AMQP. Legacy Qpid is also very important but in a different way. Qpid was traditionally about AMQP in terms of the broker. Since AMQP 1.0 the exchange/queue broker model is less important but still VERY important as a specific AMQP solution for many users. (Before anyone gets on my case I will also say that legacy Qpid is also about the Messaging API and that is also very very important!) I'm not sure how best these projects get homed in terms of projects in ASF or otherwise but some thoughts/observations: Proton, as a library that helps adoption of AMQP 1.0, should not be held back by legacy Qpid. Proton itself will evolve and is already doing so by the fact that ActiveMQ is already consuming it. And that's how we want this to happen. If so called "competitors" (and I don't necessarily mean ActiveMQ) are consuming proton that's a good thing, and it's also beyond our control. Proton can be consumed and will be consumed (hopefully) by other projects. Great! Excellent! Go AMQP 1.0. Go proton. It's a wonderful thing if proton becomes the de facto library for advancement of AMQP. What about legacy Qpid? What about brokers in general? Once "we" put out proton that all became a very different conversation. The tail wagging the dog. I see a place where there are AMQP (proton) based solutions. I don't see one broker. I do see consolidation of effort but I see different solutions. Perhaps some part of the community continues to invest time and effort in a C/C++ based broker that solves a specific problem. Perhaps the ActiveMQ based broker solves another class of problems. Perhaps some new "fashionable" project gets started somewhere else (or at Qpid) that solves a different "routing" problem. Perhaps someone develops a new language API at Qpid. Maybe someone in Mozilla builds a AMQP plugin using proton. Proton has let the cat out of the bag. IF we try to reign it in we might lose some very good momentum for AMQP. What we don't want to happen is that the current Qpid broker "product" or solution should hold back what proton can potentially do best: drive wider and faster AMQP adoption. qpid.apache.org can still be a home for many AMQP based solutions and could presumably still be a home to proton. BUT if qpid.apache.org could/would hold back proton then we have to consider if it is wiser to somehow separate the efforts in some way (mailing list or otherwise). By the way, that's little different than it already is today. So to the folks that make decisions on this list: Is AMQP more important than "legacy" Qpid? Is proton about AMQP 1.0 or about "legacy" Qpid? Can Proton live at Qpid and NOT be held back by legacy Qpid? What's best for Proton and AMQP in general? Best regards, William - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proton: motivation and strategy
On 07/20/2012 06:41 PM, Rafael Schloming wrote: On Fri, 2012-07-20 at 11:20 +0100, Gordon Sim wrote: On 07/19/2012 07:03 PM, Alan Conway wrote: On the blocking front, a good messaging API should support both blocking and non-blocking use. The messaging API can certainly be extended in a backward compatible way to do so. Yes, I agree. On the easy-to-use front it seems to me that the ideal is the an easy messaging API layered over a full-control proton API, where the underlying proton API can be exposed for "advanced" users or ignored by normal users. I think there are perhaps more than two levels of ease of use. At the very 'top' level, you just care about sending and receiving with no interest in connections, sessions, sender or receivers. The 'bottom' level is full protocol control. The messaging API at present is somewhere between those. I don't actually think of the "Limited" column of the matrix, or any of the others as expressing easy vs hard. The matrix is classifying what it is you want/need to be able to do, not how hard it is to do it. Ideally functionality in every quadrant should be as easy to use as possible. Agreed, I should not have used the term 'ease of use'. Its really about the level of abstraction from the protocol interaction. Given that it's describing functionality, you could certainly define more columns based on a finer grained look at the protocol features that are available, and indeed there are different aspects to the two programming models that may ultimately make sense to call out into different rows. What I've included represents the extreme ends of the spectrum in each dimension, as that's where initial work has been focused in order to ensure the necessary flexibility. Right, the most limited set of functionality that still makes sense is simple sending and receiving messages (no explicit connections, sessions, senders, receivers). At the other end of the spectrum you have full control over all aspects supported by the protocol. In some ways there is increasing 'functionality' as you move away from direct interaction with the protocol. E.g connection pooling, perhaps transparent replay etc, However you also get less control over the protocol, which may in itself be a loss of some functionality. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proton: motivation and strategy
On Thu, 2012-07-19 at 14:03 -0400, Alan Conway wrote: > On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote: > > > > I've personally invested a lot of time and effort in the qpid messaging > > API. It was specifically geared to transitioning to 1.0. I personally > > feel there is much to recommend it still. My desire would be to find a > > way for this to 'blend in' with the APIs developing under proton in some > > way. > > > > However I agree with Rafi's analysis of the different facets of use; I > > find his account of the evolution of proton in this respect compelling. > > I think it would be foolish to stick rigidly to the past despite a > > deeper, richer understanding of the API space emerging. > > > > I believe that what users really want is not 4 entirely separate APIs, > > but something that transitions from one use case to another more > > smoothly. Ideally I don't want to have to learn all 4 APIs to see which > > one best fits my requirements; ideally I don't want a new requirement in > > relat > > my system to force me onto an entirely different API. > > > > Rafi's axes were blocking/non-blocking and > easy-to-use/full-control-of-protocol. > > On the blocking front, a good messaging API should support both blocking > and non-blocking use. The messaging API can certainly be extended in a > backward compatible way to do so. > > On the easy-to-use front it seems to me that the ideal is the an easy > messaging API layered over a full-control proton API, where the > underlying proton API can be exposed for "advanced" users or ignored by > normal users. As I mentioned in my reply to Gordon, I don't think of the "Limited" column meaning easy-to-use per/se (although there is obviously some correlation), I would think easy vs hard probably maps as much to the blocking vs non blocking rows, since often people find non-blocking difficult. The key difference in the columns is exposure to the low level details of what's going on. The interface to the messenger API is pretty much just: send(global-address, message) The messenger implementation will under the covers open the necessary connections, sessions, and links required to deliver the messages you pass to it. In interface it's very much like the sendmail program, except it's a lot smarter and more powerful since it does pooling and what not behind the scenes, and of course it can receive messages in a similar way as well with global subscriptions. This is obviously a very different paradigm from say the messaging API or the engine where you have explicit control over exactly what connections, sessions, and links are created and you manage them all yourself. This is why I suspect a complete implementation of the feature space within the matrix may actually be a small suite of integrated APIs rather than a single API. It's hard to imagine a single API that will do both what messenger does and what messaging does, but it's easy and quite useful for both those APIs to use the same message abstraction. --Rafael - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-3963) A federated broker may not reconnect to a remote cluster on link failure.
[ https://issues.apache.org/jira/browse/QPID-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-3963: - Assignee: Justin Ross (was: Ken Giusti) > A federated broker may not reconnect to a remote cluster on link failure. > - > > Key: QPID-3963 > URL: https://issues.apache.org/jira/browse/QPID-3963 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.14 >Reporter: Ken Giusti >Assignee: Justin Ross > Fix For: 0.17 > > > When a broker is federated with a cluster, the cluster informs the broker of > the failover addresses that are valid for the cluster. Should a cluster > member fail, the broker will reconnect to another member of that cluster. > However, the federated broker only queries the cluster for these failover > addresses when it first connects to the cluster. Should the cluster topology > change, the federated broker's list of available failover addresses will > become out-of-date. This can prevent the broker from correctly re-connecting > on failure of a cluster member. > Example: > Given cluster with members C1 and C2, and a separate broker B, federate B to > connect to C1. On connecting to C1, B learns the addresses of C2 as an > alternate failover address. Now shutdown C1. B will reconnect to C2, and > learn that C2 is the only member of the cluster (ie. no failover addresses). > After B connects, restart C1 and let it join the cluster. Then shutdown C2. > Since B does not know that C1 has become available again, B will not > attempt to re-connect to it. Instead, it tries to reconnect to C2 > indefinately. > The expected behavior would be to have B reconnect to C1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proton: motivation and strategy
On Fri, 2012-07-20 at 11:20 +0100, Gordon Sim wrote: > On 07/19/2012 07:03 PM, Alan Conway wrote: > > On the blocking front, a good messaging API should support both blocking > > and non-blocking use. The messaging API can certainly be extended in a > > backward compatible way to do so. > > Yes, I agree. > > > On the easy-to-use front it seems to me that the ideal is the an easy > > messaging API layered over a full-control proton API, where the > > underlying proton API can be exposed for "advanced" users or ignored by > > normal users. > > I think there are perhaps more than two levels of ease of use. At the > very 'top' level, you just care about sending and receiving with no > interest in connections, sessions, sender or receivers. The 'bottom' > level is full protocol control. The messaging API at present is > somewhere between those. I don't actually think of the "Limited" column of the matrix, or any of the others as expressing easy vs hard. The matrix is classifying what it is you want/need to be able to do, not how hard it is to do it. Ideally functionality in every quadrant should be as easy to use as possible. Given that it's describing functionality, you could certainly define more columns based on a finer grained look at the protocol features that are available, and indeed there are different aspects to the two programming models that may ultimately make sense to call out into different rows. What I've included represents the extreme ends of the spectrum in each dimension, as that's where initial work has been focused in order to ensure the necessary flexibility. --Rafael - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4155) qpid-stat fails while trying to display queue names that have non-ascii characters
[ https://issues.apache.org/jira/browse/QPID-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-4155. Resolution: Fixed > qpid-stat fails while trying to display queue names that have non-ascii > characters > -- > > Key: QPID-4155 > URL: https://issues.apache.org/jira/browse/QPID-4155 > Project: Qpid > Issue Type: Bug > Components: Python Tools >Affects Versions: 0.18 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 0.18 > > > If a queue (or exchange) is created with a name that contains non-ascii > characters, qpid-stat will error out while attempting to display the list of > queues or exchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4158) HA transition to CATCHUP status too early.
[ https://issues.apache.org/jira/browse/QPID-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419272#comment-13419272 ] Gordon Sim commented on QPID-4158: -- Merged to 0.18 release branch as r1363852. > HA transition to CATCHUP status too early. > -- > > Key: QPID-4158 > URL: https://issues.apache.org/jira/browse/QPID-4158 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Previously we set status to CATCHUP when the BrokerReplicators bridge was > initialized. This is too early, it's possible for an aborted attempt to > connect to another backup to get as far as bridge init. This patch waits till > we receive the first actual message from the primary before updating status > to CATCHUP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4156) HA close window for clients to connect before HA broker is initialized
[ https://issues.apache.org/jira/browse/QPID-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419273#comment-13419273 ] Gordon Sim commented on QPID-4156: -- Merged on to 0.18 release branch as r1363839. > HA close window for clients to connect before HA broker is initialized > -- > > Key: QPID-4156 > URL: https://issues.apache.org/jira/browse/QPID-4156 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > A HA backup broker in a cluster rejects client connections. This was > previously done in a ConnectionObserver registered during Plugin::initialize. > However that left a window before the observer was registered when clients > could connect. This showed up as a sporadic failure of the failover test. > This patch moves the creation of the observer to Plugin::earlyInitialize, > which is guaranteed to be called before the broker starts listening for > clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4151) [Java Broker] Add validation for reserved exchange names into management web UI
[ https://issues.apache.org/jira/browse/QPID-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419253#comment-13419253 ] Robbie Gemmell commented on QPID-4151: -- Converted to sub task of QPID-3999 > [Java Broker] Add validation for reserved exchange names into management web > UI > > > Key: QPID-4151 > URL: https://issues.apache.org/jira/browse/QPID-4151 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-4151-Java-Broker-Add-validation-for-reserved-ex.patch > > > Add validation for reserved exchange names into management web UI. > Creation of exchanges with names like qpid.*, amq.* or <> should be > prohibited in web UI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4151) [Java Broker] Add validation for reserved exchange names into management web UI
[ https://issues.apache.org/jira/browse/QPID-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4151: - Issue Type: Sub-task (was: Improvement) Parent: QPID-3999 > [Java Broker] Add validation for reserved exchange names into management web > UI > > > Key: QPID-4151 > URL: https://issues.apache.org/jira/browse/QPID-4151 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-4151-Java-Broker-Add-validation-for-reserved-ex.patch > > > Add validation for reserved exchange names into management web UI. > Creation of exchanges with names like qpid.*, amq.* or <> should be > prohibited in web UI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4151) [Java Broker] Add validation for reserved exchange names into management web UI
[ https://issues.apache.org/jira/browse/QPID-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4151: - Affects Version/s: (was: 0.19) Fix Version/s: (was: 0.19) 0.18 Change was merged onto the 0.18 branch after approval on the dev list by Justin. > [Java Broker] Add validation for reserved exchange names into management web > UI > > > Key: QPID-4151 > URL: https://issues.apache.org/jira/browse/QPID-4151 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-4151-Java-Broker-Add-validation-for-reserved-ex.patch > > > Add validation for reserved exchange names into management web UI. > Creation of exchanges with names like qpid.*, amq.* or <> should be > prohibited in web UI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4150) [Java Broker] Display sortKey/lvqKey/priorities values for sorted/LVQ/prioritie queues accordingly in web management UI
[ https://issues.apache.org/jira/browse/QPID-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419249#comment-13419249 ] Robbie Gemmell commented on QPID-4150: -- Converted to sub-task of QPID-3999. > [Java Broker] Display sortKey/lvqKey/priorities values for > sorted/LVQ/prioritie queues accordingly in web management UI > --- > > Key: QPID-4150 > URL: https://issues.apache.org/jira/browse/QPID-4150 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-3999-Display-the-name-of-queue-type-key-sortKet.patch > > > Display sortKey/lvqQueue/priorities values for sorted/LVQ/prioritie queues > accordingly in web management UI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4150) [Java Broker] Display sortKey/lvqKey/priorities values for sorted/LVQ/prioritie queues accordingly in web management UI
[ https://issues.apache.org/jira/browse/QPID-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4150: - Issue Type: Sub-task (was: Improvement) Parent: QPID-3999 > [Java Broker] Display sortKey/lvqKey/priorities values for > sorted/LVQ/prioritie queues accordingly in web management UI > --- > > Key: QPID-4150 > URL: https://issues.apache.org/jira/browse/QPID-4150 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-3999-Display-the-name-of-queue-type-key-sortKet.patch > > > Display sortKey/lvqQueue/priorities values for sorted/LVQ/prioritie queues > accordingly in web management UI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4149) [Java Broker]Add functionality to delete exchanges, queues and bindings from management web UI and REST interfaces
[ https://issues.apache.org/jira/browse/QPID-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4149: - Affects Version/s: (was: 0.19) Fix Version/s: (was: 0.19) 0.18 Change was merged onto the 0.18 branch after approval on the dev list by Justin. > [Java Broker]Add functionality to delete exchanges, queues and bindings from > management web UI and REST interfaces > -- > > Key: QPID-4149 > URL: https://issues.apache.org/jira/browse/QPID-4149 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-3999-QPID-3998-Add-REST-functionality-to-delete.patch > > > Add functionality to delete exchanges, queues and bindings from management > web UI and REST interfaces -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4150) [Java Broker] Display sortKey/lvqKey/priorities values for sorted/LVQ/prioritie queues accordingly in web management UI
[ https://issues.apache.org/jira/browse/QPID-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4150: - Affects Version/s: (was: 0.19) Fix Version/s: (was: 0.19) 0.18 Change was merged onto the 0.18 branch after approval on the dev list by Justin. > [Java Broker] Display sortKey/lvqKey/priorities values for > sorted/LVQ/prioritie queues accordingly in web management UI > --- > > Key: QPID-4150 > URL: https://issues.apache.org/jira/browse/QPID-4150 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.18 > > Attachments: > 0001-QPID-3999-Display-the-name-of-queue-type-key-sortKet.patch > > > Display sortKey/lvqQueue/priorities values for sorted/LVQ/prioritie queues > accordingly in web management UI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4149) [Java Broker]Add functionality to delete exchanges, queues and bindings from management web UI and REST interfaces
[ https://issues.apache.org/jira/browse/QPID-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419244#comment-13419244 ] Robbie Gemmell commented on QPID-4149: -- Converted to sub-task of QPID-3999, though its technically as much of a sub-task of QPID-3998. > [Java Broker]Add functionality to delete exchanges, queues and bindings from > management web UI and REST interfaces > -- > > Key: QPID-4149 > URL: https://issues.apache.org/jira/browse/QPID-4149 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Affects Versions: 0.19 >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.19 > > Attachments: > 0001-QPID-3999-QPID-3998-Add-REST-functionality-to-delete.patch > > > Add functionality to delete exchanges, queues and bindings from management > web UI and REST interfaces -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4149) [Java Broker]Add functionality to delete exchanges, queues and bindings from management web UI and REST interfaces
[ https://issues.apache.org/jira/browse/QPID-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4149: - Issue Type: Sub-task (was: Improvement) Parent: QPID-3999 > [Java Broker]Add functionality to delete exchanges, queues and bindings from > management web UI and REST interfaces > -- > > Key: QPID-4149 > URL: https://issues.apache.org/jira/browse/QPID-4149 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Affects Versions: 0.19 >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.19 > > Attachments: > 0001-QPID-3999-QPID-3998-Add-REST-functionality-to-delete.patch > > > Add functionality to delete exchanges, queues and bindings from management > web UI and REST interfaces -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4155) qpid-stat fails while trying to display queue names that have non-ascii characters
[ https://issues.apache.org/jira/browse/QPID-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated QPID-4155: --- Fix Version/s: (was: 0.19) 0.18 > qpid-stat fails while trying to display queue names that have non-ascii > characters > -- > > Key: QPID-4155 > URL: https://issues.apache.org/jira/browse/QPID-4155 > Project: Qpid > Issue Type: Bug > Components: Python Tools >Affects Versions: 0.18 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 0.18 > > > If a queue (or exchange) is created with a name that contains non-ascii > characters, qpid-stat will error out while attempting to display the list of > queues or exchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4155) qpid-stat fails while trying to display queue names that have non-ascii characters
[ https://issues.apache.org/jira/browse/QPID-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419198#comment-13419198 ] Justin Ross commented on QPID-4155: --- Reviewed by me. Approved for 0.18. > qpid-stat fails while trying to display queue names that have non-ascii > characters > -- > > Key: QPID-4155 > URL: https://issues.apache.org/jira/browse/QPID-4155 > Project: Qpid > Issue Type: Bug > Components: Python Tools >Affects Versions: 0.18 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 0.19 > > > If a queue (or exchange) is created with a name that contains non-ascii > characters, qpid-stat will error out while attempting to display the list of > queues or exchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Request for 0.18 inclusion
Justin, Please consider the following Jira/Commit for inclusion in 0.18. I've added utf-8 decoding of strings in the CLI table utility so the CLIs can properly display non-ascii strings. -Ted https://issues.apache.org/jira/browse/QPID-4155 http://svn.apache.org/viewvc?rev=1363795&view=rev - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: request for inclusion in 0.18
Thanks for the nice summary. Approved for 0.18. On Fri, 20 Jul 2012, Robbie Gemmell wrote: Hi Justin, I would like to request the following JIRAs / commits be considered for inclusion in 0.18. https://issues.apache.org/jira/browse/QPID-4151 http://svn.apache.org/viewvc?view=revision&revision=1363307 https://issues.apache.org/jira/browse/QPID-4150 http://svn.apache.org/viewvc?view=revision&revision=1363297 https://issues.apache.org/jira/browse/QPID-4149 http://svn.apache.org/viewvc?view=revision&revision=1363298 The changes were either done by Alex and reviewed by me, or done by both us. Part of the change can be considered a defect resolution relating to concurrent creation and deletion of queues/exchanges via the management interfaces (for both JMX and the HTTP one). The remaining includes a tiny bit of wiring up the ability to delete queues/exchanges/bindings via the HTTP interface on the broker side (ultimately using the same code already used via the JMX interface) and then the majority of the change is updating the .js files for the new webui to allow selecting things to delete. As most of the change is isolated to the new http management, it is mostly contained within the new optional plugin and as such presents a low level of risk to the broker itself. Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
request for inclusion in 0.18
Hi Justin, I would like to request the following JIRAs / commits be considered for inclusion in 0.18. https://issues.apache.org/jira/browse/QPID-4151 http://svn.apache.org/viewvc?view=revision&revision=1363307 https://issues.apache.org/jira/browse/QPID-4150 http://svn.apache.org/viewvc?view=revision&revision=1363297 https://issues.apache.org/jira/browse/QPID-4149 http://svn.apache.org/viewvc?view=revision&revision=1363298 The changes were either done by Alex and reviewed by me, or done by both us. Part of the change can be considered a defect resolution relating to concurrent creation and deletion of queues/exchanges via the management interfaces (for both JMX and the HTTP one). The remaining includes a tiny bit of wiring up the ability to delete queues/exchanges/bindings via the HTTP interface on the broker side (ultimately using the same code already used via the JMX interface) and then the majority of the change is updating the .js files for the new webui to allow selecting things to delete. As most of the change is isolated to the new http management, it is mostly contained within the new optional plugin and as such presents a low level of risk to the broker itself. Robbie
[jira] [Commented] (QPID-4158) HA transition to CATCHUP status too early.
[ https://issues.apache.org/jira/browse/QPID-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419151#comment-13419151 ] Justin Ross commented on QPID-4158: --- Reviewed by Gordon. Approved for 0.18. > HA transition to CATCHUP status too early. > -- > > Key: QPID-4158 > URL: https://issues.apache.org/jira/browse/QPID-4158 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Previously we set status to CATCHUP when the BrokerReplicators bridge was > initialized. This is too early, it's possible for an aborted attempt to > connect to another backup to get as far as bridge init. This patch waits till > we receive the first actual message from the primary before updating status > to CATCHUP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4156) HA close window for clients to connect before HA broker is initialized
[ https://issues.apache.org/jira/browse/QPID-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419150#comment-13419150 ] Justin Ross commented on QPID-4156: --- Reviewed by Gordon. Approved for 0.18. > HA close window for clients to connect before HA broker is initialized > -- > > Key: QPID-4156 > URL: https://issues.apache.org/jira/browse/QPID-4156 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > A HA backup broker in a cluster rejects client connections. This was > previously done in a ConnectionObserver registered during Plugin::initialize. > However that left a window before the observer was registered when clients > could connect. This showed up as a sporadic failure of the failover test. > This patch moves the creation of the observer to Plugin::earlyInitialize, > which is guaranteed to be called before the broker starts listening for > clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4143) Various tweaks to Java perftest configuration
[ https://issues.apache.org/jira/browse/QPID-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4143: Attachment: 0001-QPID-4143-exclude-qpid-client-and-its-third-party-li.patch Exclude qpid-client and its third party libs from the perftests release. This makes it easier to run the perftests using an old client version. Also made logging more sensible > Various tweaks to Java perftest configuration > - > > Key: QPID-4143 > URL: https://issues.apache.org/jira/browse/QPID-4143 > Project: Qpid > Issue Type: Improvement > Components: Java Performance Tests >Affects Versions: 0.17 >Reporter: Philip Harvey >Assignee: Keith Wall >Priority: Minor > Fix For: 0.19 > > Attachments: > 0001-QPID-4143-exclude-qpid-client-and-its-third-party-li.patch, > 0001-QPID-4143-include-baseline-data-in-charts.patch, > 0001-QPID-4143-tweaked-topic-test-config-to-introduce-a-s.patch > > > The java/perftests/ module is functional, but some of the test JSON/JS files > need to be tweaked, and some error reporting should be improved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proton: motivation and strategy
On 07/19/2012 07:03 PM, Alan Conway wrote: On the blocking front, a good messaging API should support both blocking and non-blocking use. The messaging API can certainly be extended in a backward compatible way to do so. Yes, I agree. On the easy-to-use front it seems to me that the ideal is the an easy messaging API layered over a full-control proton API, where the underlying proton API can be exposed for "advanced" users or ignored by normal users. I think there are perhaps more than two levels of ease of use. At the very 'top' level, you just care about sending and receiving with no interest in connections, sessions, sender or receivers. The 'bottom' level is full protocol control. The messaging API at present is somewhere between those. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4158) HA transition to CATCHUP status too early.
[ https://issues.apache.org/jira/browse/QPID-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419021#comment-13419021 ] Gordon Sim commented on QPID-4158: -- I'm in favour of merging this to the 0.18 branch. It is a simple fix with very limited scope and impact (all with the HA feature) and it fixes a sporadic test failure. > HA transition to CATCHUP status too early. > -- > > Key: QPID-4158 > URL: https://issues.apache.org/jira/browse/QPID-4158 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Previously we set status to CATCHUP when the BrokerReplicators bridge was > initialized. This is too early, it's possible for an aborted attempt to > connect to another backup to get as far as bridge init. This patch waits till > we receive the first actual message from the primary before updating status > to CATCHUP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4156) HA close window for clients to connect before HA broker is initialized
[ https://issues.apache.org/jira/browse/QPID-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419019#comment-13419019 ] Gordon Sim commented on QPID-4156: -- I'm in favour of merging this to the release branch. Since the release candidate has not yet been cut this would seem to have no impact on others. The changes are restricted to the new HA feature. Any glitches like these that we can fix for the 0.18 release will make uptake of this alternative to clustering smoother. > HA close window for clients to connect before HA broker is initialized > -- > > Key: QPID-4156 > URL: https://issues.apache.org/jira/browse/QPID-4156 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > A HA backup broker in a cluster rejects client connections. This was > previously done in a ConnectionObserver registered during Plugin::initialize. > However that left a window before the observer was registered when clients > could connect. This showed up as a sporadic failure of the failover test. > This patch moves the creation of the observer to Plugin::earlyInitialize, > which is guaranteed to be called before the broker starts listening for > clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
