Re: AMQP broker connection with multiple certificates
On 06/16/2012 06:56 PM, Qpid_user wrote: Hi, I have a requirement whereby I need to connect to the same AMQP broker, however with different certificate aliases as each client uses different certificate. As ssl_cert_alias has to be specified in the connection string, does this mean that it is would be necessary to create multiple connections to the same broker for each client If you want each client to be authenticated in SSL using their own certificate then you have to have a separate SSL connection for each. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.18 release update - upcoming dates
Hi Justin, on the Java Broker we're doing a fair amount of work on a new web-based management console which we want to have in for 0.18. We're currently doing this work on a branch that's tracking trunk. We *could* merge this to trunk now, but we prefer only to merge work which is fully completed and tested (the branch is pretty much alpha quality right now). Given that pretty much all the Java Broker developers are working on this, and the change is essentially orthogonal to the rest of the Java Broker... do you have any objections if we delay merging this down until closer to the July 2nd date? I think this actually decreases risk for the 0.18 release as by the time we merge down we'll be more confident that there's no showstoppers being put onto the trunk ahead of the 0.18 branch. Cheers, Rob On 12 June 2012 04:49, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 July We branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3914) SSL Client Authentication support for the Windows C++ client
[ https://issues.apache.org/jira/browse/QPID-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395823#comment-13395823 ] Michal Zerola commented on QPID-3914: - OK. Which modification do you prefer then: - disable completely passing certificates from the command line - disable passing the host (public) certificate from the command line and keep only the possibility to pass the private key (which doesn't require manipulation of the Trusted Root Certification Authority store) SSL Client Authentication support for the Windows C++ client Key: QPID-3914 URL: https://issues.apache.org/jira/browse/QPID-3914 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.14, 0.16 Environment: Windows (all versions) Reporter: JAkub Scholz Attachments: ssl-client-auth-filecert.patch, ssl-client-authentication.patch The Windows C++ client has been missing support for the SSL Client Authentication - authentication using SSL certificates on the client side. The patch attached to this JIRA implements this feature. -- 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-3914) SSL Client Authentication support for the Windows C++ client
[ https://issues.apache.org/jira/browse/QPID-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395885#comment-13395885 ] Andrew Stitcher commented on QPID-3914: --- I don't think you've explained why you need to make the client install anything in the machines certificate stores using the client code itself. Why not install any certificates you need using some powershell script say when you install the client? I don't like adding a feature to the client code that seems to me to be purely administration code. SSL Client Authentication support for the Windows C++ client Key: QPID-3914 URL: https://issues.apache.org/jira/browse/QPID-3914 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.14, 0.16 Environment: Windows (all versions) Reporter: JAkub Scholz Attachments: ssl-client-auth-filecert.patch, ssl-client-authentication.patch The Windows C++ client has been missing support for the SSL Client Authentication - authentication using SSL certificates on the client side. The patch attached to this JIRA implements this feature. -- 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
Reviewboard appears to be back
So code reviews can continue as before. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3914) SSL Client Authentication support for the Windows C++ client
[ https://issues.apache.org/jira/browse/QPID-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395898#comment-13395898 ] Michal Zerola commented on QPID-3914: - One of the reason of extending the client for certificate options was to make it convenient for users to provide certificates on the command line to the application + be able to transfer application to another machine with certificates and be able to execute it without any administration needed. This is what one can easily do with Linux client. I am not sure if you have studied the patch, but the client's private key can be provided to the application without any modification of the machine's store. The public key of the server where client attempts to connect has to be in the Trusted Root store in order to accept the connection. Currently, with the patch, during the connection hand-shaking, the window is popped up (the same way as when one adds certificate to the store in a Windows traditional way) and the user can decide whether to import the certificate or not. If you are aware of any other way how to provide the public key to the client from the filesystem, please let me know. I understand your opinion, therefore I have proposed the 2 options above. SSL Client Authentication support for the Windows C++ client Key: QPID-3914 URL: https://issues.apache.org/jira/browse/QPID-3914 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.14, 0.16 Environment: Windows (all versions) Reporter: JAkub Scholz Attachments: ssl-client-auth-filecert.patch, ssl-client-authentication.patch The Windows C++ client has been missing support for the SSL Client Authentication - authentication using SSL certificates on the client side. The patch attached to this JIRA implements this feature. -- 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
[Java] Qpid API over the C++ client
Hi All, I've been working on providing a Java version of the Qpid API (QPID-4001) For starters I have experimented on implementing this API over the existing C++ client via SWIG/JNI until we get a pure Java implementation based on Rob Godfrey's proton-j work. There are some unique benefits provided by the above approach. 1. Allow us to leverage the arguable more performant and stable c++ client. 2. If we get a JMS layer over this, it can provide a reasonable alternative for the current JMS client, until we rework the client properly. 3. RDMA support for the Java client. The work I have done lives in the following branch [1] At the moment it has full support for message headers, String, List and Map messages. I have a working example here [2] that demonstrates the above. Instructions on how to run the example is here [3]. I'm hoping to get this on trunk in time for 0-18 provided the following goals are met. 1. Successful review of the c++ components [will post the details shortly]. 2. Agreement on QPID-4001 (will post the latest shortly) 3. Successful review of the common java code in the implementation layer [need to think on how best to put this up for review]. 4. Adding a reasonable amount of unit tests for the java side. I would really appreciate if interested parties have a look at the review requests and provide feedback/suggestions to make this a reality. I will be posting relative performance numbers once I get the chance to do a reasonable performance evaluation comparing this work with the current c++ client and JMS client. Regards, Rajith [1] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/ [2] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/cpp/CppTest.java [3] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/README - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.18 release update - upcoming dates
Hi Justin, I would like to get the work I have done on the Qpid Java API implementation over the c++ client into trunk for the 0.18 release. This is a completely independent piece and would like to include as an experimental feature for the 0.18 release. I'm putting up the pieces for review as we speak. Depending on how the reviews go it may miss the alpha deadline. Therefore it would be great if I get a bit of flexibility in landing this work onto trunk. Regards, Rajith On Mon, Jun 18, 2012 at 6:27 AM, Rob Godfrey rob.j.godf...@gmail.com wrote: Hi Justin, on the Java Broker we're doing a fair amount of work on a new web-based management console which we want to have in for 0.18. We're currently doing this work on a branch that's tracking trunk. We *could* merge this to trunk now, but we prefer only to merge work which is fully completed and tested (the branch is pretty much alpha quality right now). Given that pretty much all the Java Broker developers are working on this, and the change is essentially orthogonal to the rest of the Java Broker... do you have any objections if we delay merging this down until closer to the July 2nd date? I think this actually decreases risk for the 0.18 release as by the time we merge down we'll be more confident that there's no showstoppers being put onto the trunk ahead of the 0.18 branch. Cheers, Rob On 12 June 2012 04:49, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 July We branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [Java] Qpid API over the C++ client
Hi Rajith, I know you've been working on getting a JMS client over messaging API working, but this is the first I realized that the intention was to add *another* Java client for 0.18. the goal of JMS on top of messaging on top of proton makes a lot of sense... I'm less convinced that JMS on top of the current C++ client makes a lot of sense - especially without a wider discussion on the list amongst all the Java developers. Perfectly happy to have this in some sort of sandbox for people to download and try out (if they really need a JMS over RDMA client or something)... but I think adding it to the main release artefacts for 0.18 would be confusing and likely to leave us with more future support problems. -- Rob On 18 June 2012 17:00, Rajith Attapattu rajit...@gmail.com wrote: Hi All, I've been working on providing a Java version of the Qpid API (QPID-4001) For starters I have experimented on implementing this API over the existing C++ client via SWIG/JNI until we get a pure Java implementation based on Rob Godfrey's proton-j work. There are some unique benefits provided by the above approach. 1. Allow us to leverage the arguable more performant and stable c++ client. 2. If we get a JMS layer over this, it can provide a reasonable alternative for the current JMS client, until we rework the client properly. 3. RDMA support for the Java client. The work I have done lives in the following branch [1] At the moment it has full support for message headers, String, List and Map messages. I have a working example here [2] that demonstrates the above. Instructions on how to run the example is here [3]. I'm hoping to get this on trunk in time for 0-18 provided the following goals are met. 1. Successful review of the c++ components [will post the details shortly]. 2. Agreement on QPID-4001 (will post the latest shortly) 3. Successful review of the common java code in the implementation layer [need to think on how best to put this up for review]. 4. Adding a reasonable amount of unit tests for the java side. I would really appreciate if interested parties have a look at the review requests and provide feedback/suggestions to make this a reality. I will be posting relative performance numbers once I get the chance to do a reasonable performance evaluation comparing this work with the current c++ client and JMS client. Regards, Rajith [1] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/ [2] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/cpp/CppTest.java [3] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/README - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [Java] Qpid API over the C++ client
Rob, Let me clarify a few points. Perhaps my initial message wasn't clear. (*) At this point there is no plan to add a JMS layer for 0.18 (*) The JMS layer would be a generic implementation over the messaging API, and independent of any API implementation. (*) When we do add a JMS layer (likely in 0.20) on top of messaging, then this layer could be *equally* used by both a pure Java version or the cpp binding, as the JMS layer would be independent of any of it. There want be (and should not be) a JMS layer specific to the C++ client or any other implementation.. (*) The cpp binding is going to be just another implementation parallel to the pure Java implementation. And a user should be able to pick a specific impl with something like, -Dqpid.connection-factory=org.apache.qpid.messaging.cpp.CppConnectionFactory I'm only requesting this to be landed on the trunk similar to the way we have amqp-1-0-client amqp-1-0-common ..etc I totally agree that we should not be publishing this as a release artefact. We should only mention this in the notes as experimental work. And people who want to try it out, do so with the understanding that it's experimental at best. Regards, Rajith On Mon, Jun 18, 2012 at 11:13 AM, Rob Godfrey rob.j.godf...@gmail.com wrote: Hi Rajith, I know you've been working on getting a JMS client over messaging API working, but this is the first I realized that the intention was to add *another* Java client for 0.18. the goal of JMS on top of messaging on top of proton makes a lot of sense... I'm less convinced that JMS on top of the current C++ client makes a lot of sense - especially without a wider discussion on the list amongst all the Java developers. Perfectly happy to have this in some sort of sandbox for people to download and try out (if they really need a JMS over RDMA client or something)... but I think adding it to the main release artefacts for 0.18 would be confusing and likely to leave us with more future support problems. -- Rob On 18 June 2012 17:00, Rajith Attapattu rajit...@gmail.com wrote: Hi All, I've been working on providing a Java version of the Qpid API (QPID-4001) For starters I have experimented on implementing this API over the existing C++ client via SWIG/JNI until we get a pure Java implementation based on Rob Godfrey's proton-j work. There are some unique benefits provided by the above approach. 1. Allow us to leverage the arguable more performant and stable c++ client. 2. If we get a JMS layer over this, it can provide a reasonable alternative for the current JMS client, until we rework the client properly. 3. RDMA support for the Java client. The work I have done lives in the following branch [1] At the moment it has full support for message headers, String, List and Map messages. I have a working example here [2] that demonstrates the above. Instructions on how to run the example is here [3]. I'm hoping to get this on trunk in time for 0-18 provided the following goals are met. 1. Successful review of the c++ components [will post the details shortly]. 2. Agreement on QPID-4001 (will post the latest shortly) 3. Successful review of the common java code in the implementation layer [need to think on how best to put this up for review]. 4. Adding a reasonable amount of unit tests for the java side. I would really appreciate if interested parties have a look at the review requests and provide feedback/suggestions to make this a reality. I will be posting relative performance numbers once I get the chance to do a reasonable performance evaluation comparing this work with the current c++ client and JMS client. Regards, Rajith [1] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/ [2] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/cpp/CppTest.java [3] https://svn.apache.org/repos/asf/qpid/branches/address-refactor2/qpid/java/client-api/README - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-686) requeue and release should make messages available atomically
[ https://issues.apache.org/jira/browse/QPID-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-686. - Resolution: Won't Fix requeue and release should make messages available atomically - Key: QPID-686 URL: https://issues.apache.org/jira/browse/QPID-686 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M3 Reporter: Gordon Sim Assignee: Gordon Sim Currently released or requeued (which is now the case for rolledback messages) are pushed onto the front of the queue in reverse order so as to preserve original ordering if no subscribers are active. Though the AMQP spec doesn't require it, it would be much better to do this atomically such that if there are active subscribers they don't receive these messages out of order w.r.t each other (though they may unavoidably be out of order w.r.t earlier deliveries). -- 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: [Java] Qpid API over the C++ client
Rob, I agree with your plan! All though the work is independent and doesn't effect existing code, it's indeed going to be a basis for future work and we want to get it right. So I will continue with the review process, but will not land the code until everybody gets a chance to have a look at the code and is happy with it. This most likely means we will have to wait until we branch for 0.18 We can make the current work available as experimental via an appropriately named branch. I will create this branch from the same rev Justin will use for the 0.18 release branch. We can make a note in our release notes about this. Since the work is independent, interested parties could also add the patch cleanly on top of trunk and get it going any time they want. Regards, Rajith On Mon, Jun 18, 2012 at 12:12 PM, Rob Godfrey rob.j.godf...@gmail.com wrote: So, I think for me the worry is that building a JMS layer on top of the Messaging API is a key part of our future strategy for the Java/JMS client. As such I really don't want to try to rush to get this in to 0.18 before we've all had a chance to properly review things. In particular I would rather have the Java development community 1) review and agree the translation of the messaging API into Java 2) build (or utilise an existing) comprehensive test suite of Messaging API functionality which completely defines the responsibilities of this layer 3) agree how the JMS layer will layer on top of the Messaging API, clearly defining where responsibilities lie 4) build a JMS layer with an accompanying comprehensive unit test suite that again completely defines the expected functionality uysing a mock Messaging API to ensure we are isolating testing *only* to the JMS layer. My concern about landing the work on trunk too early is that we neglect the necessary design discussion and clarification, and instead we run head first into accelerated bug-fix and maintenance cycles that have proved so costly for us in the past. I think that we need to avoid repeating our past mistakes and concentrate on building the quality into the client up front. As such I'd personally rather hold off on landing the experimental code just yet, but I do think it makes sense to make these artefacts available to people who are interested in them. Cheers, Rob On 18 June 2012 17:37, Rajith Attapattu rajit...@gmail.com wrote: Rob, Let me clarify a few points. Perhaps my initial message wasn't clear. (*) At this point there is no plan to add a JMS layer for 0.18 (*) The JMS layer would be a generic implementation over the messaging API, and independent of any API implementation. (*) When we do add a JMS layer (likely in 0.20) on top of messaging, then this layer could be *equally* used by both a pure Java version or the cpp binding, as the JMS layer would be independent of any of it. There want be (and should not be) a JMS layer specific to the C++ client or any other implementation.. (*) The cpp binding is going to be just another implementation parallel to the pure Java implementation. And a user should be able to pick a specific impl with something like, -Dqpid.connection-factory=org.apache.qpid.messaging.cpp.CppConnectionFactory I'm only requesting this to be landed on the trunk similar to the way we have amqp-1-0-client amqp-1-0-common ..etc I totally agree that we should not be publishing this as a release artefact. We should only mention this in the notes as experimental work. And people who want to try it out, do so with the understanding that it's experimental at best. Regards, Rajith On Mon, Jun 18, 2012 at 11:13 AM, Rob Godfrey rob.j.godf...@gmail.com wrote: Hi Rajith, I know you've been working on getting a JMS client over messaging API working, but this is the first I realized that the intention was to add *another* Java client for 0.18. the goal of JMS on top of messaging on top of proton makes a lot of sense... I'm less convinced that JMS on top of the current C++ client makes a lot of sense - especially without a wider discussion on the list amongst all the Java developers. Perfectly happy to have this in some sort of sandbox for people to download and try out (if they really need a JMS over RDMA client or something)... but I think adding it to the main release artefacts for 0.18 would be confusing and likely to leave us with more future support problems. -- Rob On 18 June 2012 17:00, Rajith Attapattu rajit...@gmail.com wrote: Hi All, I've been working on providing a Java version of the Qpid API (QPID-4001) For starters I have experimented on implementing this API over the existing C++ client via SWIG/JNI until we get a pure Java implementation based on Rob Godfrey's proton-j work. There are some unique benefits provided by the above approach. 1. Allow us to leverage the arguable more performant and stable c++ client. 2. If we get a JMS layer over this, it can provide a
Re: 0.18 release update - upcoming dates
Hi, Steve. Reading QPID-3914, it seems there are some questions about the patches' readiness. Do you think it's ready for inclusion? (If so, please indicate in the jira's comments so point and counterpoint are in one place.) As to timing in general, I'd be willing to accept a patch for this up to beta, provided we agree it should go in. Justin On Tue, 12 Jun 2012, Steve Huston wrote: I'd like to get the patch for QPID-3914 included. I should be able to get it in this week or next. -Steve On Jun 11, 2012, at 10:49 PM, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 JulyWe branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.18 release update - upcoming dates
Hi, Rob. I don't have any objections. Since I feel better if I ask at least one question: does the console branch contain any important changes to the broker model or its operation? If not, I consider it safe to include up to beta. Justin On Mon, 18 Jun 2012, Rob Godfrey wrote: Hi Justin, on the Java Broker we're doing a fair amount of work on a new web-based management console which we want to have in for 0.18. We're currently doing this work on a branch that's tracking trunk. We *could* merge this to trunk now, but we prefer only to merge work which is fully completed and tested (the branch is pretty much alpha quality right now). Given that pretty much all the Java Broker developers are working on this, and the change is essentially orthogonal to the rest of the Java Broker... do you have any objections if we delay merging this down until closer to the July 2nd date? I think this actually decreases risk for the 0.18 release as by the time we merge down we'll be more confident that there's no showstoppers being put onto the trunk ahead of the 0.18 branch. Cheers, Rob On 12 June 2012 04:49, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 July We branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.18 release update - upcoming dates
Justin, As agreed on the other thread, I agree with Rob that it's better to hold on to the work I'm doing until we get more discussion/review. Most of my work (barring the C++/JNI code) are going to be used for the future client work and it's best we take more time to settle that down. Since we were not going to release this and make it available only on an experimental basis, its best we wait until we branch for the 0.18 release. I could create a branch off the same rev that you use for the release and then apply this patch to make it available for people who would want to use it. (I anyways need to move it out of my current branch as the name itself has created some confusion). Regards, Rajith On Mon, Jun 18, 2012 at 1:27 PM, Justin Ross jr...@redhat.com wrote: Hi, Steve. Reading QPID-3914, it seems there are some questions about the patches' readiness. Do you think it's ready for inclusion? (If so, please indicate in the jira's comments so point and counterpoint are in one place.) As to timing in general, I'd be willing to accept a patch for this up to beta, provided we agree it should go in. Justin On Tue, 12 Jun 2012, Steve Huston wrote: I'd like to get the patch for QPID-3914 included. I should be able to get it in this week or next. -Steve On Jun 11, 2012, at 10:49 PM, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 July We branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.18 release update - upcoming dates
On 18 June 2012 19:34, Justin Ross jr...@redhat.com wrote: Hi, Rob. I don't have any objections. Since I feel better if I ask at least one question: does the console branch contain any important changes to the broker model or its operation? If not, I consider it safe to include up to beta. Nope - there's a few minor changes, but almost all of the new code is in a plugin (the new code is essentially making things available to the plugin). If we can get this in for 0.18 then we could potentially remove the Eclipse based JMX console from this release which would reduce the size of the whole release bundle quite considerably. -- Rob Justin On Mon, 18 Jun 2012, Rob Godfrey wrote: Hi Justin, on the Java Broker we're doing a fair amount of work on a new web-based management console which we want to have in for 0.18. We're currently doing this work on a branch that's tracking trunk. We *could* merge this to trunk now, but we prefer only to merge work which is fully completed and tested (the branch is pretty much alpha quality right now). Given that pretty much all the Java Broker developers are working on this, and the change is essentially orthogonal to the rest of the Java Broker... do you have any objections if we delay merging this down until closer to the July 2nd date? I think this actually decreases risk for the 0.18 release as by the time we merge down we'll be more confident that there's no showstoppers being put onto the trunk ahead of the 0.18 branch. Cheers, Rob On 12 June 2012 04:49, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 July We branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4072) HA use backup messages in failover.
Alan Conway created QPID-4072: - Summary: HA use backup messages in failover. Key: QPID-4072 URL: https://issues.apache.org/jira/browse/QPID-4072 Project: Qpid Issue Type: Bug Reporter: Alan Conway Assignee: Alan Conway When a backup fails over to a new primary, it already has many/most of the messages it needs. ReplicatingSubscription should sync. the primary and backup queues, and not re-send messages that are already on the backup. -- 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
