[jira] [Created] (QPID-4820) Variant decoding/conversion incorrect for at least bin8, int8, uint8 data types
Andy Goldstein created QPID-4820: Summary: Variant decoding/conversion incorrect for at least bin8, int8, uint8 data types Key: QPID-4820 URL: https://issues.apache.org/jira/browse/QPID-4820 Project: Qpid Issue Type: Bug Reporter: Andy Goldstein In the toVariant method in Codecs.cpp (https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/qpid/amqp_0_10/Codecs.cpp#L99), the case statements for bin8, int8, and uint8 are incorrect. bin8 should be 0x00 (it's currently 0x01) int8 should be 0x01 (it's currently 0x02) uint8 should be 0x02 (it's currently 0x03) If you send a message like message.getProperties["key"] = boost::uint8_t(255) When you receive it, the value of that property comes out as -1, as the client incorrectly decodes the uint8 as an int8. It might be worth reviewing the entire switch block to see if anything else needs adjusting. -- 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-4644) Adaptation of Python qpidtoollibs to Ruby
[ https://issues.apache.org/jira/browse/QPID-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599285#comment-13599285 ] Andy Goldstein commented on QPID-4644: -- Initial work on this feature: https://github.com/ncdc/qpid/commit/82e6c4a96556cdf310492a9b86dcc1113c4e7bcc > Adaptation of Python qpidtoollibs to Ruby > - > > Key: QPID-4644 > URL: https://issues.apache.org/jira/browse/QPID-4644 > Project: Qpid > Issue Type: Improvement > Components: Ruby Client, Tools >Reporter: Andy Goldstein > > I have ported the Python qpidtoollibs code to Ruby. This adds a high-level > interface for querying the broker for information about exchanges, queues, > bindings, etc. and an easy way to create exchanges, queues, bindings, etc. -- 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-4644) Adaptation of Python qpidtoollibs to Ruby
Andy Goldstein created QPID-4644: Summary: Adaptation of Python qpidtoollibs to Ruby Key: QPID-4644 URL: https://issues.apache.org/jira/browse/QPID-4644 Project: Qpid Issue Type: Improvement Components: Ruby Client, Tools Reporter: Andy Goldstein I have ported the Python qpidtoollibs code to Ruby. This adds a high-level interface for querying the broker for information about exchanges, queues, bindings, etc. and an easy way to create exchanges, queues, bindings, etc. -- 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-4562) Message#reply_to= should auto-wrap the address argument in an Address if the argument is a String
[
https://issues.apache.org/jira/browse/QPID-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Goldstein updated QPID-4562:
-
Description:
It would be nice to be able to write
message.reply_to = "exchange/subject; {...}"
Message#reply_to= currently requires its argument to be an instance of the
Address class. It would be nice if it would check the class, and if it's a
String, wrap it in an Address automatically.
was:The qpid_messaging gem currently requires the argument passed to
message.reply_to= to be an Address. The other languages (c++, python) allow you
to pass a string to reply_to=. When trying to construct an address using
Qpid::Messaging::Address.new('qmf.default.topic', 'direct.xyz', :node => {:type
=> :topic}), Ruby segfaults because of a problem converting a string to a map.
It would be nice if it were possible to simply pass a string to
Message#reply_to=.
Summary: Message#reply_to= should auto-wrap the address argument in an
Address if the argument is a String (was: qpid_messaging gem doesn't support
message.reply_to = 'name/subject; {node:{...}}')
> Message#reply_to= should auto-wrap the address argument in an Address if the
> argument is a String
> -
>
> Key: QPID-4562
> URL: https://issues.apache.org/jira/browse/QPID-4562
> Project: Qpid
> Issue Type: Bug
> Components: Ruby Client
>Reporter: Andy Goldstein
>Priority: Minor
>
> It would be nice to be able to write
> message.reply_to = "exchange/subject; {...}"
> Message#reply_to= currently requires its argument to be an instance of the
> Address class. It would be nice if it would check the class, and if it's a
> String, wrap it in an Address automatically.
--
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-4562) qpid_messaging gem doesn't support message.reply_to = 'name/subject; {node:{...}}'
Andy Goldstein created QPID-4562:
Summary: qpid_messaging gem doesn't support message.reply_to =
'name/subject; {node:{...}}'
Key: QPID-4562
URL: https://issues.apache.org/jira/browse/QPID-4562
Project: Qpid
Issue Type: Bug
Components: Ruby Client
Reporter: Andy Goldstein
Priority: Minor
The qpid_messaging gem currently requires the argument passed to
message.reply_to= to be an Address. The other languages (c++, python) allow you
to pass a string to reply_to=. When trying to construct an address using
Qpid::Messaging::Address.new('qmf.default.topic', 'direct.xyz', :node => {:type
=> :topic}), Ruby segfaults because of a problem converting a string to a map.
It would be nice if it were possible to simply pass a string to
Message#reply_to=.
--
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-4482) Have the broker send unsolicited outstanding completions every n seconds
Andy Goldstein created QPID-4482: Summary: Have the broker send unsolicited outstanding completions every n seconds Key: QPID-4482 URL: https://issues.apache.org/jira/browse/QPID-4482 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andy Goldstein Priority: Minor When a Sender with capacity > 1 sends a message to a broker asynchronously, it currently won't receive completions from the broker for unsettled messages until the window is > capacity/4 (which is when the Sender calls session.flush()). Similarly, when using federation with acks enabled, the broker only flushes completions every messages, which could result in a large amount of memory usage if there is a large number of unacked messages, even if it's been seconds/minutes/hours/etc since the last message was sent over the federation link. It would be nice if in both situations the broker could be configured to send completions every n seconds, where n is configurable. This way, senders and federated brokers could receive updates on the status of their unsettled messages without having to wait to cross a "# of messages" threshold. -- 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-4401) New HA - bindings for QMF exchanges not replicated
Andy Goldstein created QPID-4401: Summary: New HA - bindings for QMF exchanges not replicated Key: QPID-4401 URL: https://issues.apache.org/jira/browse/QPID-4401 Project: Qpid Issue Type: Bug Components: C++ Clustering Reporter: Andy Goldstein Assignee: Alan Conway Priority: Minor If I manually create a binding from qmf.default.topic to a queue, that binding is not replicated to backup brokers. When a failover occurs, the binding is gone. My use case, which is for a test harness, is that I have several active-passive broker clusters. Each active broker binds all queue-related events to a queue. A separate, standalone broker used to gather statistics uses a queue route to pull the queue-related QMF statistics from each cluster. In effect, I'm aggregating all QMF stats from all clusters into a single stats broker. When I initiate a failover for one of my clusters, I lose the binding for queue-related events, so I no longer get stats from that cluster. -- 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-4290) ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted
[ https://issues.apache.org/jira/browse/QPID-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4290: - Attachment: qpid-4290.patch Diff against 0.18 > ReplicatingSubscription counts as a consumer and doesn't allow auto-delete > queues to be deleted > --- > > Key: QPID-4290 > URL: https://issues.apache.org/jira/browse/QPID-4290 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Reporter: Andy Goldstein >Assignee: Alan Conway > Attachments: qpid-4290.patch > > > If you create an auto-delete queue, the ReplicatingSubscription that backs it > up is included in the Queue's consumerCount, so auto-deletion never occurs > because consumerCount is always > 0. ReplicatingSubscriptions should not be > counted as consumers so auto deletion can succeed. -- 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-4290) ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted
Andy Goldstein created QPID-4290: Summary: ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted Key: QPID-4290 URL: https://issues.apache.org/jira/browse/QPID-4290 Project: Qpid Issue Type: Bug Components: C++ Clustering Reporter: Andy Goldstein Assignee: Alan Conway Attachments: qpid-4290.patch If you create an auto-delete queue, the ReplicatingSubscription that backs it up is included in the Queue's consumerCount, so auto-deletion never occurs because consumerCount is always > 0. ReplicatingSubscriptions should not be counted as consumers so auto deletion can succeed. -- 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-4248) HA does not replicate topic binding keys to backups
[ https://issues.apache.org/jira/browse/QPID-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4248: - Attachment: qpid-4248.patch Patch that appears to fix the issue. Still needs a unit test but I wanted to attach the patch as soon as I had it working. The issue is that QMF query responses call the binding key "bindingKey" while QMF bind events call it "key", and the code was only looking for "key". Also I'm missing the checkbox for the ASF grant, so I'll state it here - I grant the ASF rights to use this patch. > HA does not replicate topic binding keys to backups > --- > > Key: QPID-4248 > URL: https://issues.apache.org/jira/browse/QPID-4248 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.18 >Reporter: Jason Dillaman > Attachments: qpid-4248.patch > > > With HA enabled, start a primary broker and create a topic exchange, queue, > and a binding with a non-empty binding key between the exchange and queue. > Start a backup broker and notice that the binding key is missing on the > backup broker's binding. > Actions: > > qpid-config add exchange topic MyExchange > qpid-config add queue MyQueue > qpid-config bind MyExchange MyQueue MyKey > > Primary Config: > Exchange 'MyExchange' (topic) > bind [MyKey] => MyQueue > Backup Config: > Exchange 'MyExchange' (topic) > bind [] => MyQueue -- 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-4235) qmf-tool should display object data with the keys sorted
[ https://issues.apache.org/jira/browse/QPID-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4235: - Attachment: qpid-4235.patch Potential fix > qmf-tool should display object data with the keys sorted > > > Key: QPID-4235 > URL: https://issues.apache.org/jira/browse/QPID-4235 > Project: Qpid > Issue Type: Bug >Reporter: Andy Goldstein >Priority: Trivial > Attachments: qpid-4235.patch > > > When using qmf-tool like this: > query queue > show 2 > The output is not sorted, i.e. it looks like this: > qmf: show 2 > Properties: > Name Value > > === > unackedMessages 0 > consumerCountLow 1 > byteFtdDequeues 0 > ... > It is much easier to read if the property names are sorted. -- 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] [Created] (QPID-4235) qmf-tool should display object data with the keys sorted
Andy Goldstein created QPID-4235: Summary: qmf-tool should display object data with the keys sorted Key: QPID-4235 URL: https://issues.apache.org/jira/browse/QPID-4235 Project: Qpid Issue Type: Bug Reporter: Andy Goldstein Priority: Trivial Attachments: qpid-4235.patch When using qmf-tool like this: query queue show 2 The output is not sorted, i.e. it looks like this: qmf: show 2 Properties: Name Value === unackedMessages 0 consumerCountLow 1 byteFtdDequeues 0 ... It is much easier to read if the property names are sorted. -- 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-4223) [New HA] Completion isn't sent when queue that has acquired but unacknowledged messages is deleted
[
https://issues.apache.org/jira/browse/QPID-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13435731#comment-13435731
]
Andy Goldstein commented on QPID-4223:
--
Reproducer:
#include
#include
#include
#include
#include
#include
using namespace std;
using namespace qpid::messaging;
int main() {
Connection c;
c.open();
Session s1 = c.createSession();
Session s2 = c.createSession();
cout << "Sending" << endl;
s1.createSender("ready; {create:always}").send(Message());
cout << "Create r" << endl;
Receiver r = s2.createReceiver("ready; {create:receiver, delete:receiver}");
cout << "Fetch" << endl;
Message m = r.fetch();
//cout << "ack" << endl;
//s2.acknowledge();
cout << "Close r" << endl;
r.close();
//s2.sync();
//s2.close();
s1.sync();
s1.close();
c.close();
return 0;
}
> [New HA] Completion isn't sent when queue that has acquired but
> unacknowledged messages is deleted
> --
>
> Key: QPID-4223
> URL: https://issues.apache.org/jira/browse/QPID-4223
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, C++ Clustering
>Affects Versions: 0.18
>Reporter: Andy Goldstein
>Assignee: Alan Conway
>
> When testing the new HA in 0.18 (from the svn branch, revision 1370693), I've
> run into a problem where I can't run qpid-cpp-benchmark after I shut down one
> of the backups. Here's the scenario:
> Start 3 brokers (in my test on 3 different hosts) using the following command
> line:
> qpidd --auth no --load-module ha.so --ha-cluster yes --ha-brokers-url url here> --ha-replicate all
> Promote 1 of the brokers to primary. Run qpid-cpp-benchmark with the default
> options. The test should succeed and provide results. Next, quit 1 of the 2
> backups. Finally, run qpid-cpp-benchmark again. This time, it hangs.
> Looking at the output of "qpid-stat -q," I see there are some unacked
> messages that have been delivered to the running qpid-receive process.
--
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-4223) [New HA] Completion isn't sent when queue that has acquired but unacknowledged messages is deleted
[ https://issues.apache.org/jira/browse/QPID-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4223: - Summary: [New HA] Completion isn't sent when queue that has acquired but unacknowledged messages is deleted (was: Unable to run qpid-cpp-benchmark successfully after shutting down a backup) > [New HA] Completion isn't sent when queue that has acquired but > unacknowledged messages is deleted > -- > > Key: QPID-4223 > URL: https://issues.apache.org/jira/browse/QPID-4223 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.18 >Reporter: Andy Goldstein >Assignee: Alan Conway > > When testing the new HA in 0.18 (from the svn branch, revision 1370693), I've > run into a problem where I can't run qpid-cpp-benchmark after I shut down one > of the backups. Here's the scenario: > Start 3 brokers (in my test on 3 different hosts) using the following command > line: > qpidd --auth no --load-module ha.so --ha-cluster yes --ha-brokers-url url here> --ha-replicate all > Promote 1 of the brokers to primary. Run qpid-cpp-benchmark with the default > options. The test should succeed and provide results. Next, quit 1 of the 2 > backups. Finally, run qpid-cpp-benchmark again. This time, it hangs. > Looking at the output of "qpid-stat -q," I see there are some unacked > messages that have been delivered to the running qpid-receive process. -- 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-4223) Unable to run qpid-cpp-benchmark successfully after shutting down a backup
[
https://issues.apache.org/jira/browse/QPID-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13435730#comment-13435730
]
Andy Goldstein commented on QPID-4223:
--
I've been able to narrow this down to a simpler test case, and have an
explanation for what is going on (although I haven't traced it all the way to
come up with a fix yet). Here are my steps to reproduce:
Start broker 1
Start broker 2
Promote broker 1 to primary
Stop broker 2
Open connection to broker 1
Create session 1
Create session 2
Create sender using session 1 (ready; {create:always}) and send a message
Create receiver using session 2 (ready; {create:receiver, delete:receiver}) and
call fetch()
Close the receiver (important - WITHOUT acking the received message)
Call sync() on session 1 (the sending session)
Session 1's sync() call will hang because it is waiting for the completion of
the message.transfer command it sent, but the QueueGuard for the (now dead)
backup is keeping the command from completing.
> Unable to run qpid-cpp-benchmark successfully after shutting down a backup
> --
>
> Key: QPID-4223
> URL: https://issues.apache.org/jira/browse/QPID-4223
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, C++ Clustering
>Affects Versions: 0.18
>Reporter: Andy Goldstein
>Assignee: Alan Conway
>
> When testing the new HA in 0.18 (from the svn branch, revision 1370693), I've
> run into a problem where I can't run qpid-cpp-benchmark after I shut down one
> of the backups. Here's the scenario:
> Start 3 brokers (in my test on 3 different hosts) using the following command
> line:
> qpidd --auth no --load-module ha.so --ha-cluster yes --ha-brokers-url url here> --ha-replicate all
> Promote 1 of the brokers to primary. Run qpid-cpp-benchmark with the default
> options. The test should succeed and provide results. Next, quit 1 of the 2
> backups. Finally, run qpid-cpp-benchmark again. This time, it hangs.
> Looking at the output of "qpid-stat -q," I see there are some unacked
> messages that have been delivered to the running qpid-receive process.
--
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] [Created] (QPID-4223) Unable to run qpid-cpp-benchmark successfully after shutting down a backup
Andy Goldstein created QPID-4223: Summary: Unable to run qpid-cpp-benchmark successfully after shutting down a backup Key: QPID-4223 URL: https://issues.apache.org/jira/browse/QPID-4223 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.18 Reporter: Andy Goldstein Assignee: Alan Conway When testing the new HA in 0.18 (from the svn branch, revision 1370693), I've run into a problem where I can't run qpid-cpp-benchmark after I shut down one of the backups. Here's the scenario: Start 3 brokers (in my test on 3 different hosts) using the following command line: qpidd --auth no --load-module ha.so --ha-cluster yes --ha-brokers-url --ha-replicate all Promote 1 of the brokers to primary. Run qpid-cpp-benchmark with the default options. The test should succeed and provide results. Next, quit 1 of the 2 backups. Finally, run qpid-cpp-benchmark again. This time, it hangs. Looking at the output of "qpid-stat -q," I see there are some unacked messages that have been delivered to the running qpid-receive process. -- 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] [Created] (QPID-4190) Performance issue with new HA
Andy Goldstein created QPID-4190: Summary: Performance issue with new HA Key: QPID-4190 URL: https://issues.apache.org/jira/browse/QPID-4190 Project: Qpid Issue Type: Bug Reporter: Andy Goldstein When testing out the new HA implementation, I've noticed that if you rate limit your senders and receivers appropriately, the system runs in a steady state without any noticeable degradation in throughput. But if you instead increase the rate above the "comfortable" threshold, the end-to-end send and receive rates vary greatly. -- 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-4077) Load-balance delivery of messages across bindings
[ https://issues.apache.org/jira/browse/QPID-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4077: - Attachment: QPID-4077-load-balanced-bindings.patch Proposed patch. Load balancing is achieved by examining the queue's policy and delivering the message to the queue that has the most available free space or # of messages. Note: if you send messages with no body, and the queue's policy is only size-based, this won't have any effect. > Load-balance delivery of messages across bindings > - > > Key: QPID-4077 > URL: https://issues.apache.org/jira/browse/QPID-4077 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Andy Goldstein >Priority: Minor > Attachments: QPID-4077-load-balanced-bindings.patch > > > When an exchange receives a message that it needs to route, currently it will > deliver it to all queues that have matching bindings. It may be useful to be > able to load balance the routing of messages across a group of queues, > instead of delivering to all of them. For example, if you have one exchange > and 3 queues: q1, q2, q3. You could create bindings like this: > qpid-config bind amq.topic q1 "usa.#" qpid.binding.load-balanced=1 > qpid-config bind amq.topic q2 "usa.#" qpid.binding.load-balanced=1 > qpid-config bind amq.topic q3 "usa.#" qpid.binding.load-balanced=1 > When amq.topic receives a message that matches usa.#, it would try to > round-robin the delivery of messages to q1, q2, and q3, instead of delivering > a copy of each message to each queue. -- 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] [Created] (QPID-4077) Load-balance delivery of messages across bindings
Andy Goldstein created QPID-4077: Summary: Load-balance delivery of messages across bindings Key: QPID-4077 URL: https://issues.apache.org/jira/browse/QPID-4077 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andy Goldstein Priority: Minor When an exchange receives a message that it needs to route, currently it will deliver it to all queues that have matching bindings. It may be useful to be able to load balance the routing of messages across a group of queues, instead of delivering to all of them. For example, if you have one exchange and 3 queues: q1, q2, q3. You could create bindings like this: qpid-config bind amq.topic q1 "usa.#" qpid.binding.load-balanced=1 qpid-config bind amq.topic q2 "usa.#" qpid.binding.load-balanced=1 qpid-config bind amq.topic q3 "usa.#" qpid.binding.load-balanced=1 When amq.topic receives a message that matches usa.#, it would try to round-robin the delivery of messages to q1, q2, and q3, instead of delivering a copy of each message to each queue. -- 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] [Created] (QPID-4076) Change bridge message credit to value less than infinity
Andy Goldstein created QPID-4076: Summary: Change bridge message credit to value less than infinity Key: QPID-4076 URL: https://issues.apache.org/jira/browse/QPID-4076 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andy Goldstein Priority: Minor Attachments: QPID-4076-bridge-credit-2x-sync.patch When creating a federation bridge, currently the subscription is given infinite message credit. This allows the source broker to send messages to the destination broker as fast as it can, as many as it can. It might help overall system stability if the message credit were smaller, such as 2 times the sync frequency. -- 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-4076) Change bridge message credit to value less than infinity
[ https://issues.apache.org/jira/browse/QPID-4076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4076: - Attachment: QPID-4076-bridge-credit-2x-sync.patch Proposed patch > Change bridge message credit to value less than infinity > > > Key: QPID-4076 > URL: https://issues.apache.org/jira/browse/QPID-4076 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Andy Goldstein >Priority: Minor > Attachments: QPID-4076-bridge-credit-2x-sync.patch > > > When creating a federation bridge, currently the subscription is given > infinite message credit. This allows the source broker to send messages to > the destination broker as fast as it can, as many as it can. It might help > overall system stability if the message credit were smaller, such as 2 times > the sync frequency. -- 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-4074) Broker should default link and bridge names if not supplied to createObject
[ https://issues.apache.org/jira/browse/QPID-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4074: - Attachment: QPID-4074-default-link-and-bridge-names-via-create.patch Proposed patch > Broker should default link and bridge names if not supplied to createObject > --- > > Key: QPID-4074 > URL: https://issues.apache.org/jira/browse/QPID-4074 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Andy Goldstein >Priority: Minor > Attachments: QPID-4074-default-link-and-bridge-names-via-create.patch > > > When creating a link or a bridge via the broker's QMF "create" method, the > name of the new object is now required. The qpid-route tool still uses the > older methods to create these (broker-connect, link-bridge), and it doesn't > support specifying a name for a link or bridge, so the broker defaults the > link or bridge name to a reasonable value. When using the "create" method, > however, no such defaulting takes place. I'd like to see the link and bridge > names use the same defaulting logic if no name is supplied to "create." -- 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] [Created] (QPID-4074) Broker should default link and bridge names if not supplied to createObject
Andy Goldstein created QPID-4074: Summary: Broker should default link and bridge names if not supplied to createObject Key: QPID-4074 URL: https://issues.apache.org/jira/browse/QPID-4074 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andy Goldstein Priority: Minor When creating a link or a bridge via the broker's QMF "create" method, the name of the new object is now required. The qpid-route tool still uses the older methods to create these (broker-connect, link-bridge), and it doesn't support specifying a name for a link or bridge, so the broker defaults the link or bridge name to a reasonable value. When using the "create" method, however, no such defaulting takes place. I'd like to see the link and bridge names use the same defaulting logic if no name is supplied to "create." -- 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-4040) Destination federation broker needs to close connection if heartbeats are missed
[ https://issues.apache.org/jira/browse/QPID-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4040: - Attachment: qpid-4040.patch Patch to address the issue. This also adds a new broker option, link-heartbeat-interval, which allows the end user to control how often a heartbeat should occur for a federation link. > Destination federation broker needs to close connection if heartbeats are > missed > > > Key: QPID-4040 > URL: https://issues.apache.org/jira/browse/QPID-4040 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein >Assignee: Ted Ross > Attachments: qpid-4040.patch > > > When setting up a federation link, the destination broker never checks to see > if it's missed heartbeats from its peer (the source broker). As such, if > network connectivity is lost to the source broker, the destination broker > continues to believe that the link is operational. To fix this, the > destination broker should verify that it is still receiving heartbeats, and > forcefully close the connection to the source broker if it isn't. -- 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] [Created] (QPID-4040) Destination federation broker needs to close connection if heartbeats are missed
Andy Goldstein created QPID-4040: Summary: Destination federation broker needs to close connection if heartbeats are missed Key: QPID-4040 URL: https://issues.apache.org/jira/browse/QPID-4040 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Andy Goldstein When setting up a federation link, the destination broker never checks to see if it's missed heartbeats from its peer (the source broker). As such, if network connectivity is lost to the source broker, the destination broker continues to believe that the link is operational. To fix this, the destination broker should verify that it is still receiving heartbeats, and forcefully close the connection to the source broker if it isn't. -- 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-4036) Failed client connections permanently exhaust broker's max connections limit
[
https://issues.apache.org/jira/browse/QPID-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287405#comment-13287405
]
Andy Goldstein commented on QPID-4036:
--
This sounds similar to QPID-3438, which was supposed to be fixed in 0.16...
> Failed client connections permanently exhaust broker's max connections limit
>
>
> Key: QPID-4036
> URL: https://issues.apache.org/jira/browse/QPID-4036
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: 0.16
> Environment: CentOS release 5.5 (Final)
> Linux 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64
> x86_64 GNU/Linux
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>Reporter: Paul Colby
>Priority: Critical
> Labels: sasl, ssl
>
> I'm running a set of Qpid 0.16 C++ brokers with configuration like:
> {code}
> cluster-name="mm-queue-cluster"
> cluster-cman=yes
> cluster-mechanism=PLAIN
> cluster-username=broker
> cluster-password=abc123
> cluster-url=ssl:gateway02:5671
> auth=yes
> ssl-cert-db=/etc/qpid/certs/broker
> ssl-cert-password-file=/etc/qpid/certs/pass.txt
> ssl-cert-name=broker.messagemedia.com.au
> require-encryption=yes
> {code}
> ie the broker is requiring both encryption and authentication (configured
> SASL mech list is CRAM-MD5 DIGEST-MD5 EXTERNAL PLAIN).
> Now, if a client (let's use {{qpid-stat}} for example) connects via SSL
> (amqps) and authenticates successfully, then everything is happy.
> However, if a client repeatedly fails to use SSL and/or fails to provide
> credentials, then the broker loses one of it's configured max connections
> every time!
> So, for example, if we start the broker using the configuration shown above,
> then do this:
> {code}for i in `seq 1 550`; do echo $i; qpid-stat -q ; done{code}
> The above loop will report ~ 500 {{AuthenticationFailure}} errors, then
> switch to {{ConnectionError}} errors. Once the {{ConnectionError}} errors
> begin, all further connections to the broker will be rejected - permanently
> (until the broker is restarted), with the broker logging:
> {code}error Client max connection count limit exceeded: 500 connection
> refused{code}
> From my testing, the following loops never cause an issue (with this
> configuration):
> {code:none}
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://guest/guest@localhost
> -q ; done # Works as expected.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://guest/wrong@localhost
> -q ; done # AuthenticationFailure as expected.
> {code}
> Whereas any of the following will break the broker:
> {code:none}
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://guest/guest@localhost
> -q ; done # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://guest/wrong@localhost
> -q ; done # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://localhost -q ; done
> # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://localhost -q ; done
> # AuthenticationFailure, then ConnectionError.
> {code}
--
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-3503) Expiry exchange option for queue
[ https://issues.apache.org/jira/browse/QPID-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3503: - Attachment: expiryExchange.diff Initial attempt at a patch to add the expiry exchange feature > Expiry exchange option for queue > > > Key: QPID-3503 > URL: https://issues.apache.org/jira/browse/QPID-3503 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Andy Goldstein >Priority: Minor > Attachments: expiryExchange.diff > > > One of our clients is interested in logging information about any message > that the broker discards because the message expired (ttl). Because our > client's logging requirements are specific to the system we're building for > them, rather than trying to modify the log message the broker generates when > it discards an expired message, we've created an option that can be set on a > queue called qpid.expiry_exchange. If set, whenever the broker discards an > expired message, instead of just deleting it, it will send it to the > specified expiry exchange. This way, we can bind a queue to the expiry > exchange and attach a separate Receiver to the queue to receive these expired > messages and log them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3503) Expiry exchange option for queue
Expiry exchange option for queue Key: QPID-3503 URL: https://issues.apache.org/jira/browse/QPID-3503 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andy Goldstein Priority: Minor Attachments: expiryExchange.diff One of our clients is interested in logging information about any message that the broker discards because the message expired (ttl). Because our client's logging requirements are specific to the system we're building for them, rather than trying to modify the log message the broker generates when it discards an expired message, we've created an option that can be set on a queue called qpid.expiry_exchange. If set, whenever the broker discards an expired message, instead of just deleting it, it will send it to the specified expiry exchange. This way, we can bind a queue to the expiry exchange and attach a separate Receiver to the queue to receive these expired messages and log them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3487) Client should send completions when closing a receiver
Client should send completions when closing a receiver
--
Key: QPID-3487
URL: https://issues.apache.org/jira/browse/QPID-3487
Project: Qpid
Issue Type: Bug
Components: C++ Client
Reporter: Andy Goldstein
When closing a receiver for a queue that is either delete:always or
auto-delete:true, it is possible for the queue to remain visible in management
(qmf) even though the client has already acknowledged, released, or rejected
all messages.
Steps to reproduce:
1) Create receiver e.g. my-queue; {create:always, delete:always, node:
{x-declare: {auto-delete: true}}}
2) Set capacity to something e.g. 10
3) Send messages to my-queue
4) Call get() on the receiver for each message
5) Ack/release/reject each message
6) Close the receiver
7) IMPORTANT: keep the session alive
Expected results: "qpid-stat -q" will not show my-queue in the list
Actual results: "qpid-stat -q" shows my-queue in the list
This happens because the broker has instances of DeliveryRecord in memory for
each message that the receiver acquired, and each DeliveryRecord has a
shared_ptr to the Queue. Because the receiver does not necessarily send
completions for all the message.transfer commands, DeliveryRecords will still
be around, which means the Queue will still be visible via management.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
[ https://issues.apache.org/jira/browse/QPID-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103727#comment-13103727 ] Andy Goldstein edited comment on QPID-3481 at 9/13/11 4:35 PM: --- After talking to my developer, what we are going to do is set capacity to 0, session.reject() all acquired messages, close the receiver (thus deleting the queue), and close the session. This should fix our issue. Not all of our queues are auto-delete queues, so there are times when we want the closing of the receiver to result in the queue being deleted. There is still a small potential for message loss in general - with a queue with delete:always, acquire a message, then close the receiver and session. The message is lost because the DeliveryRecord still exists when the receiver is closed/queue is deleted. When the session is closed, the DeliveryRecord goes away, restoring the message to the (deleted) queue, and then the queue's destructor is called, but the restored message is never sent to the alternate exchange. was (Author: ncdc): After talking to my developer, what we are going to do is set capacity to 0, session.reject() all acquired messages, close the receiver (thus deleting the queue), and close the session. This should fix our issue. Not all of our queues are auto-delete queues, so there are times when we want the closing of the receiver to result in the queue being deleted. There is still a small potential for message loss in general - with a non-auto-delete queue with delete:always, acquire a message, then close the receiver and session. The message is lost because the DeliverRecord still exists when the receiver is closed/queue is deleted. When the session is closed, the DeliveryRecord goes away, restoring the message to the (deleted) queue, and then the queue's destructor is called, but the restored message is never sent to the alternate exchange. > Acquired messages are not sent to alternate exchange when queue is deleted > and receiver's session closed > > > Key: QPID-3481 > URL: https://issues.apache.org/jira/browse/QPID-3481 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein >Priority: Minor > Attachments: QPID-3481.diff > > > Currently, the broker will lose messages in the following scenario: > 1. Client creates receiver to a queue (queue has an alternate exchange > configured) > 2. Client acquires message from queue > 3. Client closes receiver (with delete:always or delete:receiver) > 4. Client closes session > We expect that the messages should be sent to the now-deleted queue's > alternate exchange if/when they are released. > Messages are not sent to the alternate exchange immediately upon closure of > the receiver because the client still has acquired messages; this is fine, > but when the client either releases the messages or closes the session, these > messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
[ https://issues.apache.org/jira/browse/QPID-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3481: - Priority: Minor (was: Major) Changing the priority to minor as this is less of an impact to us. > Acquired messages are not sent to alternate exchange when queue is deleted > and receiver's session closed > > > Key: QPID-3481 > URL: https://issues.apache.org/jira/browse/QPID-3481 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein >Priority: Minor > Attachments: QPID-3481.diff > > > Currently, the broker will lose messages in the following scenario: > 1. Client creates receiver to a queue (queue has an alternate exchange > configured) > 2. Client acquires message from queue > 3. Client closes receiver (with delete:always or delete:receiver) > 4. Client closes session > We expect that the messages should be sent to the now-deleted queue's > alternate exchange if/when they are released. > Messages are not sent to the alternate exchange immediately upon closure of > the receiver because the client still has acquired messages; this is fine, > but when the client either releases the messages or closes the session, these > messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
[ https://issues.apache.org/jira/browse/QPID-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103727#comment-13103727 ] Andy Goldstein commented on QPID-3481: -- After talking to my developer, what we are going to do is set capacity to 0, session.reject() all acquired messages, close the receiver (thus deleting the queue), and close the session. This should fix our issue. Not all of our queues are auto-delete queues, so there are times when we want the closing of the receiver to result in the queue being deleted. There is still a small potential for message loss in general - with a non-auto-delete queue with delete:always, acquire a message, then close the receiver and session. The message is lost because the DeliverRecord still exists when the receiver is closed/queue is deleted. When the session is closed, the DeliveryRecord goes away, restoring the message to the (deleted) queue, and then the queue's destructor is called, but the restored message is never sent to the alternate exchange. > Acquired messages are not sent to alternate exchange when queue is deleted > and receiver's session closed > > > Key: QPID-3481 > URL: https://issues.apache.org/jira/browse/QPID-3481 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein > Attachments: QPID-3481.diff > > > Currently, the broker will lose messages in the following scenario: > 1. Client creates receiver to a queue (queue has an alternate exchange > configured) > 2. Client acquires message from queue > 3. Client closes receiver (with delete:always or delete:receiver) > 4. Client closes session > We expect that the messages should be sent to the now-deleted queue's > alternate exchange if/when they are released. > Messages are not sent to the alternate exchange immediately upon closure of > the receiver because the client still has acquired messages; this is fine, > but when the client either releases the messages or closes the session, these > messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
[ https://issues.apache.org/jira/browse/QPID-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103577#comment-13103577 ] Andy Goldstein commented on QPID-3481: -- To give a little more context: our application uses a Receiver w/capacity > 0 to pull messages from a queue. These messages are acquired (but not immediately acked), transmitted to an external system, and this transmission may fail. If the transmission fails (exception), we catch it and close the receiver, which deletes the queue. The queue has an alternate exchange, and we need all messages to be routed to it. I believe we're modifying our catch block now to release acquired messages prior to closing the receiver, but I don't believe that will fix the message loss issue without some sort of patch. > Acquired messages are not sent to alternate exchange when queue is deleted > and receiver's session closed > > > Key: QPID-3481 > URL: https://issues.apache.org/jira/browse/QPID-3481 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein > Attachments: QPID-3481.diff > > > Currently, the broker will lose messages in the following scenario: > 1. Client creates receiver to a queue (queue has an alternate exchange > configured) > 2. Client acquires message from queue > 3. Client closes receiver (with delete:always or delete:receiver) > 4. Client closes session > We expect that the messages should be sent to the now-deleted queue's > alternate exchange if/when they are released. > Messages are not sent to the alternate exchange immediately upon closure of > the receiver because the client still has acquired messages; this is fine, > but when the client either releases the messages or closes the session, these > messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
[ https://issues.apache.org/jira/browse/QPID-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103574#comment-13103574 ] Andy Goldstein commented on QPID-3481: -- While I agree that it would be ideal to avoid this situation, there are times in our system where this will happen. We have a high priority bug related to this issue, and would like to see it resolved. As it currently stands, if you acquire a message and then delete the queue, the queue will not have its destructor called until all the DeliveryRecords have been cleaned up. This won't happen until the client's session has been closed. When the session is closed and the destructor is called, messages that were previously acquired are returned to the "deleted" queue, and then the queue is deleted from memory. The patch I attached attempts to fix this gap; namely, it performs the same logic in Queue::destroyed() that routes all messages to the alternate exchange. At least this way, messages are not lost. > Acquired messages are not sent to alternate exchange when queue is deleted > and receiver's session closed > > > Key: QPID-3481 > URL: https://issues.apache.org/jira/browse/QPID-3481 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein > Attachments: QPID-3481.diff > > > Currently, the broker will lose messages in the following scenario: > 1. Client creates receiver to a queue (queue has an alternate exchange > configured) > 2. Client acquires message from queue > 3. Client closes receiver (with delete:always or delete:receiver) > 4. Client closes session > We expect that the messages should be sent to the now-deleted queue's > alternate exchange if/when they are released. > Messages are not sent to the alternate exchange immediately upon closure of > the receiver because the client still has acquired messages; this is fine, > but when the client either releases the messages or closes the session, these > messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
[ https://issues.apache.org/jira/browse/QPID-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3481: - Attachment: QPID-3481.diff Potential patch > Acquired messages are not sent to alternate exchange when queue is deleted > and receiver's session closed > > > Key: QPID-3481 > URL: https://issues.apache.org/jira/browse/QPID-3481 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein > Attachments: QPID-3481.diff > > > Currently, the broker will lose messages in the following scenario: > 1. Client creates receiver to a queue (queue has an alternate exchange > configured) > 2. Client acquires message from queue > 3. Client closes receiver (with delete:always or delete:receiver) > 4. Client closes session > We expect that the messages should be sent to the now-deleted queue's > alternate exchange if/when they are released. > Messages are not sent to the alternate exchange immediately upon closure of > the receiver because the client still has acquired messages; this is fine, > but when the client either releases the messages or closes the session, these > messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3481) Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed Key: QPID-3481 URL: https://issues.apache.org/jira/browse/QPID-3481 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Andy Goldstein Currently, the broker will lose messages in the following scenario: 1. Client creates receiver to a queue (queue has an alternate exchange configured) 2. Client acquires message from queue 3. Client closes receiver (with delete:always or delete:receiver) 4. Client closes session We expect that the messages should be sent to the now-deleted queue's alternate exchange if/when they are released. Messages are not sent to the alternate exchange immediately upon closure of the receiver because the client still has acquired messages; this is fine, but when the client either releases the messages or closes the session, these messages should be sent to the alternate exchange. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3357) Broker should purge more aggressively before invoking queue limit policy
Broker should purge more aggressively before invoking queue limit policy Key: QPID-3357 URL: https://issues.apache.org/jira/browse/QPID-3357 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Andy Goldstein When enqueuing a message, the broker checks the message/byte count in the queue and ensures the new message will not violate the queue's limits and limit policy (reject, ring, etc). It does not take into account messages still in the queue that have expired, which could result in a message being dropped or the oldest message being removed unnecessarily. For example, create a queue with a max count of 2 messages. Send 1 message with no ttl. Send a 2nd message with a small ttl e.g. 1 second. Wait longer then the ttl so the 2nd message expires. Try to send a 3rd message to the queue. If the queue policy is reject, you will get an exception that the queue is full. If the queue policy is ring, it will discard the 1st message (no ttl so unexpired) to make room for the new message. One possible solution would be to try to purge expired messages more aggressively, e.g. when an enqueue would exceed the limit, try to purge any expired messages, and then re-check the limit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3351) Provide ability to specify the network interface qpidd should bind to
Provide ability to specify the network interface qpidd should bind to - Key: QPID-3351 URL: https://issues.apache.org/jira/browse/QPID-3351 Project: Qpid Issue Type: New Feature Components: C++ Broker Reporter: Andy Goldstein Priority: Minor Currently, qpidd binds to all network interfaces, which may not be desirable. It would be nice to be able to specify the interface or interfaces to listen on. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3321) C++ client memory usage increases when acknowledging messages unless client explicitly calls session.sync() every so often
[ https://issues.apache.org/jira/browse/QPID-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3321: - Description: Create a C++ client that receives lots and lots of messages. Call session.acknowledge(message) on each message. If you don't call session.sync() periodically, the client application's memory usage will increase over time. Most of the memory allocated appears to be coming from qpid::client::amqp0_10::AcceptTracker::accept(qpid::framing::SequenceNumber id, qpid::client::AsyncSession& session). It looks like the broker doesn't send completions for the message acknowledgements, or if it does, not very frequently. (was: Create a C++ client that receives lots and lots of messages. Call session.acknowledge(message) on each message. If you don't call session.flush() periodically, the client application's memory usage will increase over time. Most of the memory allocated appears to be coming from qpid::client::amqp0_10::AcceptTracker::accept(qpid::framing::SequenceNumber id, qpid::client::AsyncSession& session). It looks like the broker doesn't send completions for the message acknowledgements, or if it does, not very frequently.) Summary: C++ client memory usage increases when acknowledging messages unless client explicitly calls session.sync() every so often (was: C++ client memory usage increases when acknowledging messages unless client explicitly calls session.flush() every so often) > C++ client memory usage increases when acknowledging messages unless client > explicitly calls session.sync() every so often > -- > > Key: QPID-3321 > URL: https://issues.apache.org/jira/browse/QPID-3321 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Reporter: Andy Goldstein >Assignee: Gordon Sim > > Create a C++ client that receives lots and lots of messages. Call > session.acknowledge(message) on each message. If you don't call > session.sync() periodically, the client application's memory usage will > increase over time. Most of the memory allocated appears to be coming from > qpid::client::amqp0_10::AcceptTracker::accept(qpid::framing::SequenceNumber > id, qpid::client::AsyncSession& session). It looks like the broker doesn't > send completions for the message acknowledgements, or if it does, not very > frequently. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3321) C++ client memory usage increases when acknowledging messages unless client explicitly calls session.flush() every so often
C++ client memory usage increases when acknowledging messages unless client explicitly calls session.flush() every so often --- Key: QPID-3321 URL: https://issues.apache.org/jira/browse/QPID-3321 Project: Qpid Issue Type: Bug Components: C++ Client Reporter: Andy Goldstein Create a C++ client that receives lots and lots of messages. Call session.acknowledge(message) on each message. If you don't call session.flush() periodically, the client application's memory usage will increase over time. Most of the memory allocated appears to be coming from qpid::client::amqp0_10::AcceptTracker::accept(qpid::framing::SequenceNumber id, qpid::client::AsyncSession& session). It looks like the broker doesn't send completions for the message acknowledgements, or if it does, not very frequently. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3293) ClientProperties.java: READ_BUFFER_LIMIT_PROP_NAME and WRITE_BUFFER_LIMIT_PROP_NAME constants have same value
ClientProperties.java: READ_BUFFER_LIMIT_PROP_NAME and
WRITE_BUFFER_LIMIT_PROP_NAME constants have same value
-
Key: QPID-3293
URL: https://issues.apache.org/jira/browse/QPID-3293
Project: Qpid
Issue Type: Bug
Components: Java Client
Reporter: Andy Goldstein
In org.apache.qpid.configuration.ClientProperties, both
READ_BUFFER_LIMIT_PROP_NAME and WRITE_BUFFER_LIMIT_PROP_NAME constants have
same value ("qpid.read.buffer.limit"). Presumably WRITE_BUFFER_LIMIT_PROP_NAME
should be something like "qpid.write.buffer.limit", right?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3292) Client doesn't completely honor reconnect=false Connection option
Client doesn't completely honor reconnect=false Connection option - Key: QPID-3292 URL: https://issues.apache.org/jira/browse/QPID-3292 Project: Qpid Issue Type: Bug Components: C++ Client Reporter: Andy Goldstein Priority: Critical The C++ client currently does not honor the reconnect=false Connection option correctly. If the client loses the connection to the broker, the client will attempt to reconnect one time, even if reconnect is set to false. In qpid::client::amqp0_10::ConnectionImpl::connect, the method has !tryConnect() as the condition for the "for" loop, which means that tryConnect() will be invoked at least 1 time. Next, in the loop body, it will look at the value of the reconnect setting, and stop if it's set to false. The client should not try to reconnect at all if reconnect is set to false. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3291) Broker incorrectly sets TTL to 0 for messages about to expire
Broker incorrectly sets TTL to 0 for messages about to expire - Key: QPID-3291 URL: https://issues.apache.org/jira/browse/QPID-3291 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Andy Goldstein Attachments: QPID-3291.patch When qpid::broker::Message::adjustTtl() is called prior to delivering a message to a peer, it adjusts the TTL down to reflect the time the message spent in the broker. For a message that has expired, it sets the TTL to 1. The current logic calculates the remaining TTL as the difference, in nanoseconds, between the current time and the expiration time. If this value is greater than 0, it converts the remaining TTL to milliseconds and sets it on the message; otherwise, it sets the TTL to 1. This logic could result in a message that is about to expire receiving a TTL of 0. This would occur if the remaining TTL is somewhere between 1 and 1,000,000 ns. When the division occurs to convert to ms, it would result in some number between 0 and 1, which is rounded down to 0. Instead, this value should be 1. To fix this, the remaining TTL should be compared against 1,000,000. If it is >= to that number, then the conversion can proceed successfully; otherwise, the TTL should be set to 1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3291) Broker incorrectly sets TTL to 0 for messages about to expire
[ https://issues.apache.org/jira/browse/QPID-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3291: - Attachment: QPID-3291.patch Patch to correct TTL adjustment > Broker incorrectly sets TTL to 0 for messages about to expire > - > > Key: QPID-3291 > URL: https://issues.apache.org/jira/browse/QPID-3291 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Andy Goldstein > Attachments: QPID-3291.patch > > > When qpid::broker::Message::adjustTtl() is called prior to delivering a > message to a peer, it adjusts the TTL down to reflect the time the message > spent in the broker. For a message that has expired, it sets the TTL to 1. > The current logic calculates the remaining TTL as the difference, in > nanoseconds, between the current time and the expiration time. If this value > is greater than 0, it converts the remaining TTL to milliseconds and sets it > on the message; otherwise, it sets the TTL to 1. > This logic could result in a message that is about to expire receiving a TTL > of 0. This would occur if the remaining TTL is somewhere between 1 and > 1,000,000 ns. When the division occurs to convert to ms, it would result in > some number between 0 and 1, which is rounded down to 0. Instead, this value > should be 1. > To fix this, the remaining TTL should be compared against 1,000,000. If it > is >= to that number, then the conversion can proceed successfully; > otherwise, the TTL should be set to 1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3280) Message throughput suffers in a cluster when TTL set
[ https://issues.apache.org/jira/browse/QPID-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3280: - Comment: was deleted (was: Attached potential patch to resolve issue. Added a new "cluster clock" CPG message that the cluster elder fires every so often (default is 10ms, but is configurable). Each node stores and uses the cluster clock when calculating message expiration time or determining if a message has expired. Also moved the QueueCleaner to the cluster timer when the broker is part of a cluster.) > Message throughput suffers in a cluster when TTL set > > > Key: QPID-3280 > URL: https://issues.apache.org/jira/browse/QPID-3280 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.10 >Reporter: Andy Goldstein > Attachments: cluster_ttl.diff > > > When sending a large number of messages with nonzero TTLs to a cluster, > overall message throughput drops by around 20-30% compared to messages with > TTL 0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3280) Message throughput suffers in a cluster when TTL set
[ https://issues.apache.org/jira/browse/QPID-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-3280: - Attachment: cluster_ttl.diff Potential patch to resolve issue. Added a new "cluster clock" CPG message that the cluster elder fires every so often (default is 10ms, but is configurable). Each node stores and uses the cluster clock when calculating message expiration time or determining if a message has expired. Also moved the QueueCleaner to the cluster timer when the broker is part of a cluster. > Message throughput suffers in a cluster when TTL set > > > Key: QPID-3280 > URL: https://issues.apache.org/jira/browse/QPID-3280 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.10 >Reporter: Andy Goldstein > Attachments: cluster_ttl.diff > > > When sending a large number of messages with nonzero TTLs to a cluster, > overall message throughput drops by around 20-30% compared to messages with > TTL 0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3280) Message throughput suffers in a cluster when TTL set
[ https://issues.apache.org/jira/browse/QPID-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039708#comment-13039708 ] Andy Goldstein commented on QPID-3280: -- Attached potential patch to resolve issue. Added a new "cluster clock" CPG message that the cluster elder fires every so often (default is 10ms, but is configurable). Each node stores and uses the cluster clock when calculating message expiration time or determining if a message has expired. Also moved the QueueCleaner to the cluster timer when the broker is part of a cluster. > Message throughput suffers in a cluster when TTL set > > > Key: QPID-3280 > URL: https://issues.apache.org/jira/browse/QPID-3280 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.10 >Reporter: Andy Goldstein > Attachments: cluster_ttl.diff > > > When sending a large number of messages with nonzero TTLs to a cluster, > overall message throughput drops by around 20-30% compared to messages with > TTL 0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3280) Message throughput suffers in a cluster when TTL set
Message throughput suffers in a cluster when TTL set Key: QPID-3280 URL: https://issues.apache.org/jira/browse/QPID-3280 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.10 Reporter: Andy Goldstein When sending a large number of messages with nonzero TTLs to a cluster, overall message throughput drops by around 20-30% compared to messages with TTL 0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3200) Ability to acknowledge all messages up to and including a given message for a Session
Ability to acknowledge all messages up to and including a given message for a Session - Key: QPID-3200 URL: https://issues.apache.org/jira/browse/QPID-3200 Project: Qpid Issue Type: Improvement Components: C++ Client Reporter: Andy Goldstein Currently the Session class gives us the ability to acknowledge either a single specified message, or all outstanding messages for the Session. We'd like to be able to acknowledge all messages up to and including a given message in a single method call, to save on round trip times to the broker. Our use case. 1) create receiver with capacity > 0 (e.g. 100) 2) repeat: a) receive message X from queue A b) perform business logic c) send message X to a broker (could be same broker, could be a different broker) 3) Every so often, we'd like to acknowledge messages that we're certain have been received by the broker in 2c. We can't use session.acknowledge() because it's possible some messages that we've received in 2a haven't been completed by the broker in 2c. We plan on checking the unsettled count in our sender and using that to determine which messages can be safely acknowledged. It's currently slow to ack each message individually, and we think that being able to invoke session.acknowledgeThrough(messageX) should be faster for us. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2936) XML exchange only creates external variables from application headers that are strings
XML exchange only creates external variables from application headers that are strings -- Key: QPID-2936 URL: https://issues.apache.org/jira/browse/QPID-2936 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: RHEL 5.5 Reporter: Andy Goldstein When using an XQuery expression such as declare variable $control external; $control mod 2 = 0 the XML exchange currently only creates external XQuery variables from strings. For example, if I set an application header to 4, the XML exchange does not create an external variable for it. On the other hand, if I set the header to "4" (a string), the XML exchange will create an external variable for it. It would be useful if the XML exchange supported other application header data types. I tested this on the latest code from trunk, approx. r1033046. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
