[jira] Commented: (QPID-2935) Support best effort producer flow control within the AMQP 0.10 implementation.
[ https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930163#action_12930163 ] Ken Giusti commented on QPID-2935: -- A high-level description of a proposed solution: *) Use credit to prevent queue overflow event. *) Associate watermarks with each Queue instance. Each queue would maintain a high and low watermark corresponding to a capacity level within the queue - the number of queued messages, for example, or the total number of message bytes enqueued. The watermarks would be constrained such that high_watermark = low_watermark: the high_watermark would indicate the level of capacity at and above which the queue is considered likely to overflow. The low_watermark would indicate the level at or below which the queue is no longer considered likely to overflow. *) Associate a state with each Queue instance that reflects the current level of data in the queue with respect to the watermarks. When the current level of data in the queue crosses the high_watermark, the state is set to blocking. When the current level of data in the queue falls below the low_watermark, the state will transition to normal from blocking *) Each message transferred to the broker will maintain a boolean blocked flag. After a message has been enqueued to all of the destination queues, the block flag will be set if one or more of the destination queues are in the blocking state. *) The transfer of any message which has a set blocked flag will not be completed from the point of view of the client until the flag is reset. *) A message's blocked flag will be reset when: 1) the state of all destination queues become normal or 2) the message is consumed from all queues. *) The message is completed once the blocked flag is reset. Issues with this approach: 1) the capacity level configured for a given producer must take into account the high_watermark setting of the potential destination queues. If the producer's capacity level is too high for a given queue (or the sum of all potential producer's capacity), the queue will overflow regardless of this solution. 2) A producer will be blocked based on the destination of the current set of outbound messages. A pending transfer of a message to a different - possibly unblocked - destination would be blocked by the current outstanding messages. This appears to be unavoidable given the 0.10 model. Support best effort producer flow control within the AMQP 0.10 implementation. Key: QPID-2935 URL: https://issues.apache.org/jira/browse/QPID-2935 Project: Qpid Issue Type: New Feature Components: C++ Broker, C++ Client Affects Versions: 0.9 Environment: any Reporter: Ken Giusti Assignee: Ken Giusti Fix For: Future Attachments: QPID-2935.tgz To what extent, if any, could producer flow control be supported on the existing (pre-1.0) protocol? In the current C++ broker/client implementation, when a queue on the broker fills to the point where it cannot accept any more messages (--default-queue-limit hit), the broker will forcibly disconnect any client that attempts to route a message to that queue. This is an abrupt failure - the producing client is not privy to the queue's remaining capacity. The broker provides no feedback to the producing client, which could be used to throttle the client's message production rate. The purpose of this JIRA is to explore the possible methods for implementing producer throttling on the current 0.10 C++ codebase. -- 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
[jira] Commented: (QPID-2935) Support best effort producer flow control within the AMQP 0.10 implementation.
[ https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930174#action_12930174 ] Marnie McCormack commented on QPID-2935: Hi Ken, FYI - In case you haven't already seen the docs on the flow control implementation on the Java broker: https://cwiki.apache.org/qpid/use-producer-flow-control.html https://cwiki.apache.org/qpid/producer-flow-control.html Implemented by Rob Godfrey. Regards, Marnie Support best effort producer flow control within the AMQP 0.10 implementation. Key: QPID-2935 URL: https://issues.apache.org/jira/browse/QPID-2935 Project: Qpid Issue Type: New Feature Components: C++ Broker, C++ Client Affects Versions: 0.9 Environment: any Reporter: Ken Giusti Assignee: Ken Giusti Fix For: Future Attachments: QPID-2935.tgz To what extent, if any, could producer flow control be supported on the existing (pre-1.0) protocol? In the current C++ broker/client implementation, when a queue on the broker fills to the point where it cannot accept any more messages (--default-queue-limit hit), the broker will forcibly disconnect any client that attempts to route a message to that queue. This is an abrupt failure - the producing client is not privy to the queue's remaining capacity. The broker provides no feedback to the producing client, which could be used to throttle the client's message production rate. The purpose of this JIRA is to explore the possible methods for implementing producer throttling on the current 0.10 C++ codebase. -- 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
[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
[jira] Resolved: (QPID-2934) Feature to pass the authenticated userId to QMF agent method handlers for authorization
[ https://issues.apache.org/jira/browse/QPID-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-2934. Resolution: Fixed Feature to pass the authenticated userId to QMF agent method handlers for authorization --- Key: QPID-2934 URL: https://issues.apache.org/jira/browse/QPID-2934 Project: Qpid Issue Type: New Feature Components: Qpid Managment Framework Affects Versions: 0.9 Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: 0.9 Attachments: QPID2934.diff In order to authorize method calls in QMF, the method handler needs to be provided with the authenticated user-id of the requestor (i.e. the content of the user-id message header as authenticated by the message broker). This change provides a new method to Manageable (in the C++ agent API) called AuthorizeMethod. It is virtual and may optionally be overridden by the application. If overridden, it is invoked immediately prior to the call to ManagementMethod (the method handler) with the method-id, method-arguments, and the user-id. -- 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
