[jira] Commented: (QPID-1899) --require-encryption doesn't work unless cyrus sasl authentication is turned on
[ https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12756386#action_12756386 ] Gordon Sim commented on QPID-1899: -- looks good to me --require-encryption doesn't work unless cyrus sasl authentication is turned on --- Key: QPID-1899 URL: https://issues.apache.org/jira/browse/QPID-1899 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.6 Attachments: qpid-1899-hacky.patch If you specify --require-encryption and --auth no then the broker will allow un-encrypted conections. (If on the other hand you have authentication on, it will prevent you connecting with anything other than a mech that supports encryption and will require an encrypting sasl security layer - or of course an ssl connection) -- 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-1899) --require-encryption doesn't work unless cyrus sasl authentication is turned on
[ https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12756388#action_12756388 ] Gordon Sim commented on QPID-1899: -- the external ssf also looks interesting; would that allow the negotiation to complete without a sasl negotiated encryption providing the external ssf was high enough? --require-encryption doesn't work unless cyrus sasl authentication is turned on --- Key: QPID-1899 URL: https://issues.apache.org/jira/browse/QPID-1899 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.6 Attachments: qpid-1899-hacky.patch If you specify --require-encryption and --auth no then the broker will allow un-encrypted conections. (If on the other hand you have authentication on, it will prevent you connecting with anything other than a mech that supports encryption and will require an encrypting sasl security layer - or of course an ssl connection) -- 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-942) Introduce client flow control and broker overflow protection
[ https://issues.apache.org/jira/browse/QPID-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12756437#action_12756437 ] Rob Godfrey commented on QPID-942: -- Design notes here: http://cwiki.apache.org/confluence/display/qpid/Java+Broker+-+AMQP0-9+Tactical+Producer+Flow+Control Introduce client flow control and broker overflow protection Key: QPID-942 URL: https://issues.apache.org/jira/browse/QPID-942 Project: Qpid Issue Type: New Feature Components: Java Broker, Java Client Reporter: Marnie McCormack Assignee: Rob Godfrey Fix For: 0.6 Certainly the Java, and probably the other clients do not obey flow-control commands from the broker. The Java broker never sends them to clients either. This is in the 0-8 spec. so not fully AMQP compliant without it. Client Work --- Flow control to be implemented in clients. The clients must also have buffer limiting in place prior to this, or flow-controlling a client will only shift OOMEs from the broker to the clients. Bounded buffers plus back-pressure from the broker will should ultimately lead to the 'send' method blocking once the system as a whole is completely saturated. This may mean that the broker gets a needed opportunity to chew its way through the back-log, resulting in healthy throughputs under saturation. Broker Work -- A strategy for deciding when to flow control clients from the broker needs to be decided upon. Flow-control has per-connection granularity, which makes deciding when to do it on a per route basis awkward. Flow-control may be triggered by: 1. The broker being low on memory globally across the message store and all queues. 2. A client attempting to publish to a queue that is beyond its max-depth. 3. Based on history of destinations a client usually publishes to (or has published to), flow-control client if one of them is beyond max-depth. A well-conditioned application will not experience 'send' blocking, except under exceptional loads, whereupon it will act as a safety valve to prevent either clients or broker from throwing OOME. The other scenario that may cause back-logs, is slow consumers without TTL. No time estimate for this yet, as its a fairly large piece of work, and not yet decided exactly how its to be done. Need a design proposal before starting work, to be reviewed by the qpid-dev group. -- 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-2108) ACL Enhancement to support queue limit policies
ACL Enhancement to support queue limit policies
---
Key: QPID-2108
URL: https://issues.apache.org/jira/browse/QPID-2108
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Affects Versions: 0.5
Reporter: Tim Platten
It is a requirement for us to be able to enforce queue limit policies using the
ACL authorisation mechanism. I therefore propose the following enhancement:
Add three new properties to the create queue rule: limitpolicy, maxqueuesize
and maxqueuecount. The policy test can be implemented using existing code, but
the numeric limits require a less-than-or-equal test. I.e. if a value for
maxqueuesize is specified in the ACL file, an exception will be thrown if a
value greater than this is specified in declareQueue. A value less than or
equal would be acceptable. If maxqueuecount and/or maxqueuesize were omitted
from the rule or specified as zero, the corresponding check would interpret the
value as unlimited.
Proposed code changes follow (prefixed with change-bar |).
AclModule.h
.
.
.
enum Property {PROP_NAME, PROP_DURABLE, PROP_OWNER, PROP_ROUTINGKEY,
PROP_PASSIVE, PROP_AUTODELETE, PROP_EXCLUSIVE, PROP_TYPE,
PROP_ALTERNATE, PROP_QUEUENAME, PROP_SCHEMAPACKAGE,
| PROP_SCHEMACLASS, PROP_LIMITPOLICY, PROP_MAXQUEUESIZE,
PROP_MAXQUEUECOUNT};
.
.
.
static inline Property getProperty(const std::string str) {
if (str.compare(name) == 0) return PROP_NAME;
if (str.compare(durable) == 0) return PROP_DURABLE;
if (str.compare(owner) == 0) return PROP_OWNER;
if (str.compare(routingkey) == 0) return PROP_ROUTINGKEY;
if (str.compare(passive) == 0) return PROP_PASSIVE;
if (str.compare(autodelete) == 0) return PROP_AUTODELETE;
if (str.compare(exclusive) == 0) return PROP_EXCLUSIVE;
if (str.compare(type) == 0) return PROP_TYPE;
if (str.compare(alternate) == 0) return PROP_ALTERNATE;
if (str.compare(queuename) == 0) return PROP_QUEUENAME;
if (str.compare(schemapackage) == 0) return PROP_SCHEMAPACKAGE;
if (str.compare(schemaclass) == 0) return PROP_SCHEMACLASS;
| if (str.compare(limitpolicy) == 0) return PROP_LIMITPOLICY;
| if (str.compare(maxqueuesize) == 0) return PROP_MAXQUEUESIZE;
| if (str.compare(maxqueuecount) == 0) return PROP_MAXQUEUECOUNT;
throw str;
}
static inline std::string getPropertyStr(const Property p) {
switch (p) {
case PROP_NAME: return name;
case PROP_DURABLE: return durable;
case PROP_OWNER: return owner;
case PROP_ROUTINGKEY: return routingkey;
case PROP_PASSIVE: return passive;
case PROP_AUTODELETE: return autodelete;
case PROP_EXCLUSIVE: return exclusive;
case PROP_TYPE: return type;
case PROP_ALTERNATE: return alternate;
case PROP_QUEUENAME: return queuename;
case PROP_SCHEMAPACKAGE: return schemapackage;
case PROP_SCHEMACLASS: return schemaclass;
| case PROP_LIMITPOLICY: return limitpolicy;
| case PROP_MAXQUEUESIZE: return maxqueuesize;
| case PROP_MAXQUEUECOUNT: return maxqueuecount;
default: assert(false); // should never get here
}
return ;
}
.
.
.
// == Queues ==
propSetPtr p4(new propSet);
| p4-insert(PROP_ALTERNATE);
| p4-insert(PROP_PASSIVE);
| p4-insert(PROP_DURABLE);
| p4-insert(PROP_EXCLUSIVE);
| p4-insert(PROP_AUTODELETE);
| p4-insert(PROP_LIMITPOLICY);
| p4-insert(PROP_MAXQUEUESIZE);
| p4-insert(PROP_MAXQUEUECOUNT);
Note that currently (Qpid 0.5) this code appears to be incorrectly
dereferencing p3 instead of p4.
SessionAdapter.cpp
.
.
.
void SessionAdapter::QueueHandlerImpl::declare(const string name, const
string alternateExchange,
bool passive, bool durable, bool
exclusive,
bool autoDelete, const
qpid::framing::FieldTable arguments)
{
AclModule* acl = getBroker().getAcl();
if (acl) {
std::mapacl::Property, std::string params;
params.insert(make_pair(acl::PROP_ALTERNATE, alternateExchange));
params.insert(make_pair(acl::PROP_PASSIVE, std::string(passive ? true
: false) ));
params.insert(make_pair(acl::PROP_DURABLE, std::string(durable ? true
: false)));
params.insert(make_pair(acl::PROP_EXCLUSIVE, std::string(exclusive ?
true : false)));
params.insert(make_pair(acl::PROP_AUTODELETE, std::string(autoDelete ?
true : false)));
| params.insert(make_pair(acl::PROP_LIMITPOLICY,
arguments.getAsString(qpid.policy_type)));
| params.insert(make_pair(acl::PROP_MAXQUEUECOUNT,
boost::lexical_caststring(arguments.getAsInt(qpid.max_count;
|
[jira] Assigned: (QPID-1871) During Rollback Client Rejects Message after sending TxRollback
[ https://issues.apache.org/jira/browse/QPID-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-1871: Assignee: Martin Ritchie During Rollback Client Rejects Message after sending TxRollback --- Key: QPID-1871 URL: https://issues.apache.org/jira/browse/QPID-1871 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client Affects Versions: M4, 0.5 Reporter: Martin Ritchie Assignee: Martin Ritchie Summary: See QPID-1864 for annotated log output. The log output is from a run with the Java broker, but highlights that the client dispatcher thread is not synchronized with the main thread during rollback. As a result the main thread sends the TxRollback before the Dispatcher has sent its Reject message. This results, on the java broker, in the unrejected message being redelivered, which may be out of order depending on what other messages have been released on the message queue. If we are to continue to rely on the dispatcher thread rejecting/releasing the message it is currently processing (i.e. the message that is neither in the _queue preDispatchQueue nor the _synchronousQueue for receiver delivery) then we will need to synchronize with the main thread's rollback/recover calls so that the dispatcher can finish processing its message before the rollback/recover completes. The message that the Dispatcher thread has can be seen in AMQSession L:2866:dispatchMessage(). On Rollback we stop the dispatcher (L2763) which can result in the dispatcher thread stopping on L2877 and holding on the the message it is in the middle of delivery. More likely during recover the dispatcher will block on the lock L2870. When the dispatcher is restarted (L2792) it is then free to reject its message. However, the thread that restarted the dispatcher's next call is to send the rollback command(L1553) Which is where the race condition occurs. Potential Fix: Message Rejection should be performed BEFORE we stop the dispatcher. On L:2825 we remove the message from the _queue (preDispatchQueue) and then potentailly sit on the message L:2877 when we get stopped. If the reject call in L:2888 was before the wait then we could reject the message rather than sit on it. Note: Now that I look at this a bit more the rollback (L2754) code looks to be over synchronized. I'm not sure the dispatcher will actually ever stop on the wait L2877 during rollback as the dispatcher is stopped and started again inside the one syncronisation which would prevent the dispatcher getting to the wait. So will more likely block on the sync L2870 Moving the setConnectionStopped calls out of the sync block along and ensuring that the _rollbackMark is updated before the connection is stopped then we should ok. -- 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] Updated: (QPID-1766) Implemention of selector using Xquery
[ https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenta lee updated QPID-1766: - Attachment: selector_pytest.diff Add unit tests for selector to python testing framework. I added two unit tests: 1. test_message_selector Filter the message by header and xml content. 2. test_message_selector_not_acquired Filter the message by header and xml content in browsing mode. Implemention of selector using Xquery - Key: QPID-1766 URL: https://issues.apache.org/jira/browse/QPID-1766 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Environment: Linux Reporter: chenta lee Attachments: chenta.diff, Makefile.patch, Makefile.patch, message_selector_pytest.patch, selector.diff, selector.diff, selector.patch, selector.patch, selector_broker.patch, selector_client.patch, selector_client.patch, selector_example.zip, selector_new.diff, selector_pytest.diff I implemented the message selector for C++ broker and client using Xquery. I will attach an example later. -- 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-1899) --require-encryption doesn't work unless cyrus sasl authentication is turned on
[ https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12756655#action_12756655 ] Gordon Sim commented on QPID-1899: -- I like that approach. Current patch also looks good; shall I commit that in the meantime or wait for the SSF_EXTERNAL change? --require-encryption doesn't work unless cyrus sasl authentication is turned on --- Key: QPID-1899 URL: https://issues.apache.org/jira/browse/QPID-1899 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.6 Attachments: qpid-1899-9-17.patch, qpid-1899-hacky.patch If you specify --require-encryption and --auth no then the broker will allow un-encrypted conections. (If on the other hand you have authentication on, it will prevent you connecting with anything other than a mech that supports encryption and will require an encrypting sasl security layer - or of course an ssl connection) -- 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-1899) --require-encryption doesn't work unless cyrus sasl authentication is turned on
[ https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12756692#action_12756692 ] Ken Giusti commented on QPID-1899: -- The SSF_EXTERNAL stuff doesn't appear to buy us anything: doing a sasl_getopts( SASL_SFF ) reports a negotiated ssf of zero, even if I set it to non-zero via sasl_setopts( SASL_SFF_EXTERNAL). The client (perftest) logs that there is no security layer regardless, also: 2009-09-17 14:45:30 debug No security layer in place So I don't see an advantage with the EXTERNAL stuff. I'm fine with the current patch - let's go with that. --require-encryption doesn't work unless cyrus sasl authentication is turned on --- Key: QPID-1899 URL: https://issues.apache.org/jira/browse/QPID-1899 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.6 Attachments: qpid-1899-9-17.patch, qpid-1899-hacky.patch If you specify --require-encryption and --auth no then the broker will allow un-encrypted conections. (If on the other hand you have authentication on, it will prevent you connecting with anything other than a mech that supports encryption and will require an encrypting sasl security layer - or of course an ssl connection) -- 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-2109) Windows C++ broker doesn't react properly to ctrl-c
[ https://issues.apache.org/jira/browse/QPID-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston resolved QPID-2109. Resolution: Fixed Fix Version/s: 0.6 Fixed by adding a control control handler to windows/QpiddBroker.cpp; trunk r816348 Windows C++ broker doesn't react properly to ctrl-c --- Key: QPID-2109 URL: https://issues.apache.org/jira/browse/QPID-2109 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Environment: Windows Reporter: Steve Huston Assignee: Steve Huston Fix For: 0.6 If the C++ broker on Windows gets a ctrl-c, the process gets killed without having a chance to properly clean up. This prevents the plugin finalizers from running, etc. -- 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-2110) Provide local buffering of messages on input links
Provide local buffering of messages on input links -- Key: QPID-2110 URL: https://issues.apache.org/jira/browse/QPID-2110 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen The IInputChannel and InputLink implementations are synchronous, requesting and retrieving one message at a time. Introducing a Prefetch limit corresponding to ongoing message credit to the broker provides substantial read performance benefits. -- 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] Updated: (QPID-2110) Provide local buffering of messages on input links
[ https://issues.apache.org/jira/browse/QPID-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2110: --- Attachment: channel.patch interop.patch interop.patch provides the capability to set and change the PrefetchLimit on the InputLink channel.patch provides the PrefetchLimit property on the AmqpBinding and its use in the transport channel Provide local buffering of messages on input links -- Key: QPID-2110 URL: https://issues.apache.org/jira/browse/QPID-2110 Project: Qpid Issue Type: Improvement Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Attachments: channel.patch, interop.patch The IInputChannel and InputLink implementations are synchronous, requesting and retrieving one message at a time. Introducing a Prefetch limit corresponding to ongoing message credit to the broker provides substantial read performance benefits. -- 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-1562) Better separation of 0-10 and 0-8/0-9 support in test framework
[ https://issues.apache.org/jira/browse/QPID-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12756806#action_12756806 ] Garrett Smith commented on QPID-1562: - This is not tied to the test framework: With qpid 0-5: # export AMQP_SPEC=/QPID/specs/amqp.0-8.xml # python -c import qpid Traceback (most recent call last): File string, line 1, in module File qpid/__init__.py, line 20, in module import spec, codec, connection, content, peer, delegate, client File qpid/connection.py, line 20, in module import datatypes, session, socket File qpid/session.py, line 47, in module class Session(command_invoker(SPEC)): File qpid/generator.py, line 56, in command_invoker return invoker(CommandInvoker, spec, is_command) File qpid/generator.py, line 52, in invoker (), generate(spec, invoker.__module__, predicate)) File qpid/generator.py, line 35, in generate for name, enum in spec.enums.items(): AttributeError: Spec instance has no attribute 'enums' The scheme used to specify the spec in the Python library is unorthodox and difficult to work with (and around). The meta programming used in the library should be explicit, via constructors or factory functions and not via a side effect of module loading. Unfortunately, this isn't a one or two line fix. However, it appears that 0.8 support is broken at the moment. It strikes me as odd that 0-5 was released without successfully testing 0-8 (as it appears by the original description of this issue). Is 0-8 no longer supported? Better separation of 0-10 and 0-8/0-9 support in test framework --- Key: QPID-1562 URL: https://issues.apache.org/jira/browse/QPID-1562 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: M4 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Minor From r732760 the python test suite cannot be run without either the spec refered to from qpid_config available in the expected location or the AMQP_SPEC env var set to an 0-10 format spec. Setting AMQP_SPEC to an 0-8 format spec file causes: Traceback (most recent call last): File ./run-tests, line 22, in ? from qpid.testlib import testrunner File /home/gordon/temp/python/qpid/__init__.py, line 20, in ? import spec, codec, connection, content, peer, delegate, client File /home/gordon/temp/python/qpid/connection.py, line 20, in ? import datatypes, session, socket File /home/gordon/temp/python/qpid/session.py, line 47, in ? class Session(command_invoker(SPEC)): File /home/gordon/temp/python/qpid/generator.py, line 56, in command_invoker return invoker(CommandInvoker, spec, is_command) File /home/gordon/temp/python/qpid/generator.py, line 52, in invoker (), generate(spec, invoker.__module__, predicate)) File /home/gordon/temp/python/qpid/generator.py, line 35, in generate for name, enum in spec.enums.items(): AttributeError: Spec instance has no attribute 'enums' -- 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
