[jira] [Updated] (QPID-4388) Systemd support not being installed with Cmake
[ https://issues.apache.org/jira/browse/QPID-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-4388: --- Attachment: 0001-QPID-4388-Systemd-support-not-being-installed-with-C.patch Systemd support not being installed with Cmake -- Key: QPID-4388 URL: https://issues.apache.org/jira/browse/QPID-4388 Project: Qpid Issue Type: Bug Affects Versions: 0.19 Reporter: Darryl L. Pierce Attachments: 0001-QPID-4388-Systemd-support-not-being-installed-with-C.patch The enhancement for systemd support was added to the autotools build system but not the Cmake system in QPID-4351. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (QPID-4390) Java Broker should allow runtime changes to persisted configuration
[ https://issues.apache.org/jira/browse/QPID-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4390: --- Assignee: Philip Harvey Java Broker should allow runtime changes to persisted configuration --- Key: QPID-4390 URL: https://issues.apache.org/jira/browse/QPID-4390 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.19 Reporter: Philip Harvey Assignee: Philip Harvey The design for the new configuration store is on the wiki: [https://cwiki.apache.org/confluence/display/qpid/New+design+for+the+Java+Broker+configuration] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (QPID-4389) Qpid topic exchange does not resend message when subsciber come back online
Andrew Burks created QPID-4389: -- Summary: Qpid topic exchange does not resend message when subsciber come back online Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (QPID-4390) Java Broker should allow runtime changes to persisted configuration
Philip Harvey created QPID-4390: --- Summary: Java Broker should allow runtime changes to persisted configuration Key: QPID-4390 URL: https://issues.apache.org/jira/browse/QPID-4390 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.19 Reporter: Philip Harvey The design for the new configuration store is on the wiki: [https://cwiki.apache.org/confluence/display/qpid/New+design+for+the+Java+Broker+configuration] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4389) Qpid topic exchange does not resend message when subsciber come back online
[ https://issues.apache.org/jira/browse/QPID-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Burks updated QPID-4389: --- Attachment: DurSubProject.tar.gz Attached a test project to show my steps Qpid topic exchange does not resend message when subsciber come back online --- Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks Labels: newbie Attachments: DurSubProject.tar.gz When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (QPID-4391) HA replicating subscriptions should not auto-delete queues
Alan Conway created QPID-4391: - Summary: HA replicating subscriptions should not auto-delete queues Key: QPID-4391 URL: https://issues.apache.org/jira/browse/QPID-4391 Project: Qpid Issue Type: Bug Reporter: Alan Conway Description of problem: When an auto-delete queue is replicated, the replicating subscription attempts to auto-delete the queue after it has already been auto-deleted by the closing of the last non-HA consumer. An issue occurs if a new auto-delete queue with the same name is created shortly after the deletion of the previously queue. This can occur when a client subscribes to an auto-delete queue and is temporarily disconnected from the broker. It is possible for the cancelled HA subscription to remove the newly created queue from the queue registry since the old and new queues use the same names. The HA replicating subscription should not execute the auto-delete logic when the subscription is cancelled. Version-Release number of selected component (if applicable): Qpid 0.18 How reproducible: Frequently Steps to Reproduce: Race condition between a consumer auto-deleting and recreating a queue of the same name and the HA replicating subscription auto-deleting the original queue. If the HA replicating subscription auto-deletes the original queue after the new queue is created, the new queue is removed from the queue registry. Actual results: New queue is removed from the queue registry. Expected results: HA subscription does not attempt to auto-delete the queue and therefore the new queue is not removed from the queue registry. Additional info: https://bugzilla.redhat.com/show_bug.cgi?id=868364 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (QPID-4392) C++ Broker - channel number collisions on federated links
Chuck Rolke created QPID-4392: - Summary: C++ Broker - channel number collisions on federated links Key: QPID-4392 URL: https://issues.apache.org/jira/browse/QPID-4392 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Chuck Rolke Channel numbers are allocated in counting sequence. After creating and deleting tens of thousands of bridges the channel numbers wrap around and collide with existing channels. Existing channel numbers need to be tracked so that new channel numbers are unique. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (QPID-4392) C++ Broker - channel number collisions on federated links
[ https://issues.apache.org/jira/browse/QPID-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reassigned QPID-4392: - Assignee: Chuck Rolke C++ Broker - channel number collisions on federated links - Key: QPID-4392 URL: https://issues.apache.org/jira/browse/QPID-4392 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Chuck Rolke Assignee: Chuck Rolke Channel numbers are allocated in counting sequence. After creating and deleting tens of thousands of bridges the channel numbers wrap around and collide with existing channels. Existing channel numbers need to be tracked so that new channel numbers are unique. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Resolved] (QPID-4385) Java Performance Tests should reset client registration timeout after each registration
[ https://issues.apache.org/jira/browse/QPID-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-4385. -- Resolution: Fixed Fix Version/s: 0.19 The patch looks good for me. It is committed. Java Performance Tests should reset client registration timeout after each registration --- Key: QPID-4385 URL: https://issues.apache.org/jira/browse/QPID-4385 Project: Qpid Issue Type: Improvement Components: Java Tests Affects Versions: 0.18 Reporter: Philip Harvey Assignee: Alex Rudyy Fix For: 0.19 Attachments: 0001-QPID-4385-perf-test-ClientRegistry-timeout-now-only-.patch Currently the Java perf test framework applies a timeout to the total time taken for all the clients to register with it. This is problematic if there are a lot of clients. Instead, the framework should reset its timeout each time a client registers, so that it only complains if there has been a genuinely idle period. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (QPID-4393) HA BrokerReplicator should call queue-bind, not exchange-bind
Alan Conway created QPID-4393: - Summary: HA BrokerReplicator should call queue-bind, not exchange-bind Key: QPID-4393 URL: https://issues.apache.org/jira/browse/QPID-4393 Project: Qpid Issue Type: Bug Components: C++ Clustering Reporter: Alan Conway Assignee: Alan Conway In BrokerReplicator, there are a few places that it calls exchange-bind(). We're seeing some incorrect behavior during failover testing (e.g. an exchange shows that it has 5 bindings when there is really only 1) and we think we've narrowed it down to this. Instead of calling exchange-bind(), it should call queue-bind(). If you look at qpid::broker::Broker::createObject(), you'll see that this method calls queue-bind() to bind a queue to an exchange. (Note that exchange-unbind() appears to be the correct operation for removing a binding, so this shouldn't need to be changed.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (QPID-4389) Qpid topic exchange does not resend message when subsciber come back online
[ https://issues.apache.org/jira/browse/QPID-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-4389: Assignee: Alex Rudyy Qpid topic exchange does not resend message when subsciber come back online --- Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks Assignee: Alex Rudyy Labels: newbie Attachments: DurSubProject.tar.gz When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4389) Qpid topic exchange does not resend message when subsciber come back online
[ https://issues.apache.org/jira/browse/QPID-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4389: - Component/s: (was: Java Broker) Java Client Fix Version/s: 0.19 Qpid topic exchange does not resend message when subsciber come back online --- Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks Assignee: Alex Rudyy Labels: newbie Fix For: 0.19 Attachments: DurSubProject.tar.gz When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4389) Qpid topic exchange does not resend message when subsciber come back online
[ https://issues.apache.org/jira/browse/QPID-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482865#comment-13482865 ] Alex Rudyy commented on QPID-4389: -- Hi Andrew, I looked into this issue and found that with Address based syntax the AMQP 0.10 client did not send the subscriber selector expression as part of arguments of ExchangeBind command on creation of durable subscription. As result, on closing and re-opening of durable subscriber the client tried to check whether expected and real binding arguments match and on matching failure the JMS client deleted and re-created the subscription queue on the broker. That caused the losing of all the messages on the queue. I fixed this issue on trunk. You can try to checkout fresh Qpid sources and build the java client from java sub-module by running ant command as follows: ant clean build release-bin The client build will be created in java/client/release folder. Alternatively, you can try to use Binding URL syntax for your topics as described at https://cwiki.apache.org/qpid/bindingurlformat.html . The bug does not occur when Binding URL syntax is used. Please note that you need to prefix the binding URL with BURL: as Address based syntax is used by default in java Qpid client. Also, you can use JVM setting -Dqpid.dest_syntax=BURL to set the Binding URL syntax as a default for all your queues and topics. Qpid topic exchange does not resend message when subsciber come back online --- Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks Assignee: Alex Rudyy Labels: newbie Fix For: 0.19 Attachments: DurSubProject.tar.gz When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4389) Qpid topic exchange does not resend message when subsciber come back online
[ https://issues.apache.org/jira/browse/QPID-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4389: - Status: Ready To Review (was: In Progress) Qpid topic exchange does not resend message when subsciber come back online --- Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks Assignee: Alex Rudyy Labels: newbie Fix For: 0.19 Attachments: DurSubProject.tar.gz When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (QPID-4389) Qpid topic exchange does not resend message when subsciber come back online
[ https://issues.apache.org/jira/browse/QPID-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-4389: Assignee: Robbie Gemmell (was: Alex Rudyy) Robbie, Could you please review the changes? Qpid topic exchange does not resend message when subsciber come back online --- Key: QPID-4389 URL: https://issues.apache.org/jira/browse/QPID-4389 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.14 Environment: Linux,Netbeans 7.2 Reporter: Andrew Burks Assignee: Robbie Gemmell Labels: newbie Fix For: 0.19 Attachments: DurSubProject.tar.gz When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
