[jira] Created: (QPID-2616) Qpid C++ broker: disconnect client when handshake incomplete
Qpid C++ broker: disconnect client when handshake incomplete Key: QPID-2616 URL: https://issues.apache.org/jira/browse/QPID-2616 Project: Qpid Issue Type: New Feature Components: C++ Broker Environment: Red Hat Enterprise MRG 1.2 Reporter: Armin Noll The broker should disconnect clients if the connection handshake doesn't complete after a configurable time (both for SSL and for non-SSL connections). We are looking for an implementation of this feature and will provide it as soon as we are done. -- 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-2616) Qpid C++ broker: disconnect client when handshake incomplete
[ https://issues.apache.org/jira/browse/QPID-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Armin Noll updated QPID-2616: - Description: The broker should disconnect clients if the connection handshake doesn't complete after a configurable time (both for SSL and for non-SSL connections). This feature has already been mentioned by G. Sim in the JIRA QPID-2518. We are looking for an implementation of this feature and will provide it as soon as we are done. was: The broker should disconnect clients if the connection handshake doesn't complete after a configurable time (both for SSL and for non-SSL connections). We are looking for an implementation of this feature and will provide it as soon as we are done. Qpid C++ broker: disconnect client when handshake incomplete Key: QPID-2616 URL: https://issues.apache.org/jira/browse/QPID-2616 Project: Qpid Issue Type: New Feature Components: C++ Broker Environment: Red Hat Enterprise MRG 1.2 Reporter: Armin Noll The broker should disconnect clients if the connection handshake doesn't complete after a configurable time (both for SSL and for non-SSL connections). This feature has already been mentioned by G. Sim in the JIRA QPID-2518. We are looking for an implementation of this feature and will provide it as soon as we are done. -- 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-2617) make sasl-based tests config files relocatable
make sasl-based tests config files relocatable -- Key: QPID-2617 URL: https://issues.apache.org/jira/browse/QPID-2617 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Currently, sasl-based testing is hampered by the fact that the sasl library code is only reading its configuration information from the standard installed location /etc/sasl2 . This means that sasl installation must be done manually on a machine prior to running sasl-based tests, which makes them not fully automatable. 1. Find a way of telling the library to look elsewhere 2. expose that mechanism through a broker option 3. check a suitable config file into our source tree, at cpp/src/tests 4. reference the locally-created sasldb from the new config file 5. the new sasl tests should be runnable by any users -- not just root. -- 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
Minor changes, need review
Hi. While working away on new ACL code, I have found and fixed a few little one-line and other minor issues, raised as the following JIRAs: QPID-2607, QPID-2608, QPID-2609, QPID-2610 and QPID-2611. Could someone please take a look at the patches I have attached to them, and maybe even commit if they look OK? Cheers, Andrew. -- -- andrew d kennedy ? edinburgh : +44 7941 197 134 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Persistence Message Store Plug-in for C++
Hi QPID Dev Team We have a requirement of creating a persistence message store plug-in in C++ like that of Berkley DB. We have our own message queues implementation which we want to use as a plug-in to QPID . The documentation available online does not talk much about how to develop third party message store plug-ins. Do you have some documentation / standards which the third party message store plug-in should implement / adhere to ? It would be really useful if those documents can be shared . Thanks Regards Rahul Satpathy Software Developer CA Technologies Mbl: +91-9963027925 @ http://the-rebel-speaks.blogspot.com/
[jira] Updated: (QPID-2581) Create a ConfigurationManager to allow plugins to provide configuration handling classes
[ https://issues.apache.org/jira/browse/QPID-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2581: - Attachment: (was: 0003-QPID-2581-Update-configuration-manager-to-allow-mul.patch) Create a ConfigurationManager to allow plugins to provide configuration handling classes Key: QPID-2581 URL: https://issues.apache.org/jira/browse/QPID-2581 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch To allow plugins to handle configuration add a ConfigurationManager that will load ConfigurationPlugins during the configuration process before the broker starts up. This will allow the configuration values to be processed and determined to be valid input before we actually attempt to continue broker startup. -- 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-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/Activator.java qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/PluginFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java qpid/java/broker/src/test/java/org/apache/qpid/server/plugins/MockPluginManager.java Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2569) Implement the SimpleXML as an OSGI plugin
[ https://issues.apache.org/jira/browse/QPID-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2569: - Attachment: 0007-QPID-2569-Implement-the-SimpleXML-as-an-OSGi-plugin.patch qpid/java/broker-plugins/simple-xml/MANIFEST.MF qpid/java/broker-plugins/simple-xml/build.xml qpid/java/broker-plugins/simple-xml/src/main/java/org/apache/qpid/server/security/access/config/PrincipalPermissions.java qpid/java/broker-plugins/simple-xml/src/main/java/org/apache/qpid/server/security/access/plugins/SimpleXML.java qpid/java/broker-plugins/simple-xml/src/main/java/org/apache/qpid/server/security/access/plugins/SimpleXMLActivator.java qpid/java/broker-plugins/simple-xml/src/main/java/org/apache/qpid/server/security/access/plugins/SimpleXMLConfiguration.java qpid/java/broker-plugins/simple-xml/src/test/java/org/apache/qpid/server/security/access/PrincipalPermissionsTest.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/plugins/SimpleXML.java qpid/java/systests/src/main/java/org/apache/qpid/server/security/acl/SimpleACLTest.java Implement the SimpleXML as an OSGI plugin - Key: QPID-2569 URL: https://issues.apache.org/jira/browse/QPID-2569 Project: Qpid Issue Type: Improvement Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 Attachments: 0007-QPID-2569-Implement-the-SimpleXML-as-an-OSGi-plugin.patch, simple-xml.tgz, simplexml.tgz The SimpleXML is in the main code but intended to be an OSGI plugin. -- 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
Re: Persistence Message Store Plug-in for C++
On 05/19/2010 12:51 PM, Steve Huston wrote: Hi Rahul, We have a requirement of creating a persistence message store plug-in in C++ like that of Berkley DB. We have our own message queues implementation which we want to use as a plug-in to QPID . The documentation available online does not talk much about how to develop third party message store plug-ins. Do you have some documentation / standards which the third party message store plug-in should implement / adhere to ? It would be really useful if those documents can be shared . The plug-in should adhere to the interface in qpid/cpp/src/qpid/store/StorageProvider.h. The sources in that directory are set up to offer a variety of storage providers that can be selected at run time. You can check the ms_sql directory under there for the current Windows SQL-based implementation. There is some documentation for how this works, but the web site is not too functional at this point. Try to make progress with the code and its comments. If you have any questions, feel free to ask back here. One thing to be aware of is that the APIs/ABIs for broker plugins are in no way stable at this point and are likely to undergo some changes. However having more input on that would be good and your involvement would be very much welcomed. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: (was: 0005-QPID-2606-Identify-where-ACL-permission-should-be-a.patch) Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch -- 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-2542) Implement ACL checking as OSGi plugin
[ https://issues.apache.org/jira/browse/QPID-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2542: - Attachment: (was: access-control.tgz) Implement ACL checking as OSGi plugin - Key: QPID-2542 URL: https://issues.apache.org/jira/browse/QPID-2542 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch qpid/java/broker/etc/config.xml qpid/java/broker/src/main/java/org/apache/qpid/qmf/QMFService.java qpid/java/broker/src/main/java/org/apache/qpid/server/AMQBrokerManagerMBean.java qpid/java/broker/src/main/java/org/apache/qpid/server/AMQChannel.java qpid/java/broker/src/main/java/org/apache/qpid/server/Main.java qpid/java/broker/src/main/java/org/apache/qpid/server/binding/BindingFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/configuration/QueueConfiguration.java qpid/java/broker/src/main/java/org/apache/qpid/server/configuration/ServerConfiguration.java qpid/java/broker/src/main/java/org/apache/qpid/server/exchange/AbstractExchangeMBean.java qpid/java/broker/src/main/java/org/apache/qpid/server/exchange/DefaultExchangeFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/exchange/DefaultExchangeRegistry.java qpid/java/broker/src/main/java/org/apache/qpid/server/exchange/Exchange.java qpid/java/broker/src/main/java/org/apache/qpid/server/exchange/ExchangeFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/BasicConsumeMethodHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/BasicGetMethodHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/BasicPublishMethodHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/ChannelOpenHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/ConnectionOpenMethodHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/ConnectionSecureOkMethodHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/ConnectionStartOkMethodHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/ExchangeDeclareHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/ExchangeDeleteHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/QueueBindHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/QueueDeclareHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/QueueDeleteHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/QueuePurgeHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/handler/QueueUnbindHandler.java qpid/java/broker/src/main/java/org/apache/qpid/server/management/MBeanInvocationHandlerImpl.java qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/Plugin.java qpid/java/broker/src/main/java/org/apache/qpid/server/protocol/AMQProtocolEngine.java qpid/java/broker/src/main/java/org/apache/qpid/server/queue/AMQQueue.java qpid/java/broker/src/main/java/org/apache/qpid/server/queue/AMQQueueFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/queue/AMQQueueMBean.java qpid/java/broker/src/main/java/org/apache/qpid/server/queue/SimpleAMQQueue.java qpid/java/broker/src/main/java/org/apache/qpid/server/registry/ApplicationRegistry.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/AbstractPlugin.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/AbstractProxyPlugin.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/Result.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/SecurityManager.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/SecurityPlugin.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/SecurityPluginActivator.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/SecurityPluginFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/ACLManager.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/ACLPlugin.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/ACLPluginFactory.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/AccessResult.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/AccessRights.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/Accessable.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/AuthorizationManager.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/ObjectProperties.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/ObjectType.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/Operation.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/Permission.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/PrincipalPermissions.java qpid/java/broker/src/main/java/org/apache/qpid/server/security/access/VirtualHostAccess.java
[jira] Updated: (QPID-1447) Broker does not handle with slow consumers effectively
[ https://issues.apache.org/jira/browse/QPID-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-1447: - Attachment: 0012-QPID-1447-Updated-to-use-newer-configuration-plugin.patch qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/server/configuration/plugin/SlowConsumerDetectionConfiguration.java qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/server/configuration/plugin/SlowConsumerDetectionPolicyConfiguration.java qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/server/configuration/plugin/SlowConsumerDetectionQueueConfiguration.java qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/server/virtualhost/plugin/SlowConsumerDetection.java qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/server/virtualhost/plugin/policies/TopicDeletePolicy.java qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/slowconsumerdetection/policies/SlowConsumerPolicyPlugin.java qpid/java/broker-plugins/experimental/slowconsumerdetection/src/main/java/org/apache/qpid/slowconsumerdetection/policies/SlowConsumerPolicyPluginFactory.java Broker does not handle with slow consumers effectively -- Key: QPID-1447 URL: https://issues.apache.org/jira/browse/QPID-1447 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: M3 Environment: Any Reporter: Robert Greig Assignee: Martin Ritchie Priority: Critical Attachments: 0012-QPID-1447-Updated-to-use-newer-configuration-plugin.patch Please see this qpid-user thread for further context: http://markmail.org/message/vgtssb2ivyttnbsf The qpid java broker does not deal effectively with slow consumers. This is a combination of two issues: a MINA issue and a lack of support in qpid itself. The MINA issue is similar to the fast producer issue. In this case, the data is stored in the MINA session queues, and does not appear in the queue counts which makes it very difficult for users to track down. Each MINA session event queue needs to be a bounded list. The broker also needs enhancement to offer at least two options when a queue builds up: 1) throttle the publisher. This is likely to be something that is desirable for public queues. 2) disconnect the slow consumer. This will be used when dealing with private queues - typically bound to a topic exchange. -- 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-2569) Implement the SimpleXML as an OSGI plugin
[ https://issues.apache.org/jira/browse/QPID-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2569: - Attachment: (was: simple-xml.tgz) Implement the SimpleXML as an OSGI plugin - Key: QPID-2569 URL: https://issues.apache.org/jira/browse/QPID-2569 Project: Qpid Issue Type: Improvement Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 Attachments: 0007-QPID-2569-Implement-the-SimpleXML-as-an-OSGi-plugin.patch, simplexml.tgz The SimpleXML is in the main code but intended to be an OSGI plugin. -- 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-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch qpid/java/broker-plugins/extras/MANIFEST.MF qpid/java/broker-plugins/extras/build.xml qpid/java/broker-plugins/extras/src/main/java/org/apache/qpid/extras/exchanges/diagnostic/DiagnosticExchange.java qpid/java/broker-plugins/extras/src/main/java/org/apache/qpid/extras/exchanges/example/TestExchange.java qpid/java/broker-plugins/extras/src/test/java/org/apache/qpid/server/plugins/ExtrasTest.java qpid/java/broker-plugins/extras/src/test/java/org/apache/qpid/server/plugins/PluginTest.java Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch, 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2573) Implement the Firewall functionality as an OSGI plugin
[ https://issues.apache.org/jira/browse/QPID-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2573: - Attachment: (was: firewall.tgz) Implement the Firewall functionality as an OSGI plugin -- Key: QPID-2573 URL: https://issues.apache.org/jira/browse/QPID-2573 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Fix For: 0.7 Attachments: 0008-QPID-2573-Implement-the-Firewall-functionality-as-a.patch The firewall functionality should be exposed as a OSGI plugin and detached from main tree. This allows one to use the service on demand. -- 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-2476) Complete ACL implementation for 0-10 code path
[ https://issues.apache.org/jira/browse/QPID-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869108#action_12869108 ] Andrew Kennedy commented on QPID-2476: -- The patches for QPID-2585 (both), QPID-2581, QPID-2542, QPID-2606 and QPID-1447 should be applied to test the new ACL mechanism. Apologoies for the large size of this update. I am happy to go over the purpose of the files for anyone who wants clarification, and I am in the process of writing (more) documentation. Also, there is still scope for some implementation details to change in the future, based on the outcome of discussions on qpid-dev. Andrew. Complete ACL implementation for 0-10 code path -- Key: QPID-2476 URL: https://issues.apache.org/jira/browse/QPID-2476 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.7 Reporter: Andrew Kennedy Fix For: 0.7 Original Estimate: 336h Remaining Estimate: 336h Complete ACL implementation for 0-10 code path, providing an ACLv2 implementation that covers the following features/requirements: - Best practice security design - Support for roles/groups - Appropriate for standard stores for authorisation credentials (e.g. LDAP, Kerberos) - Expressable as XML - Easy to store/backup/extract ACL config - Exception handling catching at point of ACL application and return to client via Connection ExceptionListener with correct error code, log failure in broker - No significant performance cost on publish, permissions to be cached - Security handled at correct level of abstraction internally - Interoperability with existing ACLv2 -- 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
Re: svn commit: r945945 - in /qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/client/ systests/src/main/java/org/apache/qpid/test/client/destination/
Hi Rajith is the testLinkCapacity testing some special CPP broker functionality?
+if (!isCppBroker())
+{
+_logger.info(Not C++ broker, exiting test);
+return;
+}
If it is not for the Java broker it should be excluded in the
JavaExcludes file. I know that our current exclusion method is not the
best. Solutions on a postcard ;)
However, it appears to be testing 0-10 functionality so should it not
also run against the Java broker with 0-10?
Cheers
Martin
On 19 May 2010 00:05, raj...@apache.org wrote:
Author: rajith
Date: Tue May 18 23:05:36 2010
New Revision: 945945
URL: http://svn.apache.org/viewvc?rev=945945view=rev
Log:
Implemented the feature described in QPID-2515
However a few issues needs to be ironed out - see the JIRA for these issues.
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/destination/AddressBasedDestinationTest.java
Modified:
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java?rev=945945r1=945944r2=945945view=diff
==
---
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
(original)
+++
qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
Tue May 18 23:05:36 2010
@@ -142,7 +142,7 @@ public class AMQSession_0_10 extends AMQ
* USed to store the range of in tx messages
*/
private RangeSet _txRangeSet = new RangeSet();
-private int _txSize = 0;
+private int _txSize = 0;
//--- constructors
/**
@@ -560,6 +560,9 @@ public class AMQSession_0_10 extends AMQ
throws AMQException, FailoverException
{
boolean preAcquire;
+
+long capacity = getCapacity(consumer.getDestination());
+
try
{
preAcquire = ( ! consumer.isNoConsume()
@@ -578,7 +581,7 @@ public class AMQSession_0_10 extends AMQ
String consumerTag =
((BasicMessageConsumer_0_10)consumer).getConsumerTagString();
-if (! prefetch())
+if (capacity == 0)
{
getQpidSession().messageSetFlowMode(consumerTag,
MessageFlowMode.CREDIT);
}
@@ -589,12 +592,12 @@ public class AMQSession_0_10 extends AMQ
getQpidSession().messageFlow(consumerTag, MessageCreditUnit.BYTE,
0x,
Option.UNRELIABLE);
-if(prefetch() _dispatcher != null (isStarted() ||
_immediatePrefetch))
+if(capacity 0 _dispatcher != null (isStarted() ||
_immediatePrefetch))
{
// set the flow
getQpidSession().messageFlow(consumerTag,
MessageCreditUnit.MESSAGE,
- getAMQConnection().getMaxPrefetch(),
+ capacity,
Option.UNRELIABLE);
}
@@ -604,6 +607,21 @@ public class AMQSession_0_10 extends AMQ
getCurrentException();
}
}
+
+private long getCapacity(AMQDestination destination)
+{
+long capacity = 0;
+if (destination.getDestSyntax() == DestSyntax.ADDR
+destination.getSourceLink().getCapacity() 0)
+{
+capacity = destination.getSourceLink().getCapacity();
+}
+else if (prefetch())
+{
+capacity = getAMQConnection().getMaxPrefetch();
+}
+return capacity;
+}
/**
* Create an 0_10 message producer
@@ -744,7 +762,9 @@ public class AMQSession_0_10 extends AMQ
//only set if msg list is null
try
{
-if (! prefetch())
+long capacity = getCapacity(consumer.getDestination());
+
+if (capacity == 0)
{
if (consumer.getMessageListener() != null)
{
@@ -757,7 +777,7 @@ public class AMQSession_0_10 extends AMQ
{
getQpidSession()
.messageFlow(consumerTag,
MessageCreditUnit.MESSAGE,
- getAMQConnection().getMaxPrefetch(),
+ capacity,
Option.UNRELIABLE);
}
getQpidSession()
Modified:
Re: svn commit: r945789 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/client/AMQConnectionTest.java
All Java test writers
It would make the test code much easier to read if we use
Session.TRANSACTED_SESSION when we really mean to create a transacted
session:
The intent of the following line is unclear:
+Session consSessB = _connection.createSession(true,
Session.AUTO_ACKNOWLEDGE);
Rajith did you want a Transacted session here?
Martin
On 18 May 2010 18:53, raj...@apache.org wrote:
Author: rajith
Date: Tue May 18 17:53:02 2010
New Revision: 945789
URL: http://svn.apache.org/viewvc?rev=945789view=rev
Log:
Modified the test slightly to make it work against the 0-10 code path.
Verified that it works against the C++ broker and the Java broker (both 0-8
and 0-10 codepaths).
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/client/AMQConnectionTest.java
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/client/AMQConnectionTest.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/client/AMQConnectionTest.java?rev=945789r1=945788r2=945789view=diff
==
---
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/client/AMQConnectionTest.java
(original)
+++
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/client/AMQConnectionTest.java
Tue May 18 17:53:02 2010
@@ -230,7 +230,16 @@ public class AMQConnectionTest extends Q
producer.send(producerSession.createTextMessage(test));
}
-MessageConsumer consumerB = consSessA.createConsumer(_queue);
+MessageConsumer consumerB = null;
+if (isBroker08())
+{
+Session consSessB = _connection.createSession(true,
Session.AUTO_ACKNOWLEDGE);
+consumerB = consSessB.createConsumer(_queue);
+}
+else
+{
+consumerB = consSessA.createConsumer(_queue);
+}
Message msg;
// Check that consumer A has 2 messages
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-subscr...@qpid.apache.org
--
Martin Ritchie
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [Java] Slow consumer test running out of memory
Hi Rajith, I think this is actually down to the erroneous adjustment of the ExpiredMessageTask frequency in the NullApplicationRegistry. I recent change I made was to cause HouseKeepingTasks to log when they execute. The NAR though sets the run frequency to every 200ms. This was done for one test. Which test I don't recall right now but will track it down and ensure that it sets the configuration it needs without breaking the other tests. The OOM will be due to the test framework holding on to all the broker log messages. I actually haven't seen a OOM locally on any of my full suite test runs (default,java,java.0.10) but hopefully the change to the housekeeping frequency will address this in your test env. In the mean time I beleive uping the memory avalable to ant will address this. Cheers Martin On 19 May 2010 00:09, Rajith Attapattu rajit...@gmail.com wrote: Hi Martin, The slow consumer test seems to run out of memory. Could you perhaps adjust the test or the memory requirements to ensure it doesn't go OOM ? test: [echo] Using profile:default [junit] Running org.apache.qpid.systest.SlowConsumerTest test:ExpiredMessagesTask 2010-05-18 17:38:48,908 DEBUG [qpid.server.virtualhost.VirtualHostImpl$1ExpiredMessagesTask] Checking message status for queue: ping development:ExpiredMessagesTask 2010-05-18 17:38:48,909 DEBUG [qpid.server.virtualhost.VirtualHostImpl$1ExpiredMessagesTask] Checking message status for queue: ping java.lang.OutOfMemoryError: PermGen space PermGen space Thread-1259 2010-05-18 17:38:50,812 INFO [qpid.server.registry.ApplicationRegistry] Shutting down ApplicationRegistry(1):org.apache.qpid.server.registry.configurationfileapplicationregis...@2268898 Thread-1259 2010-05-18 17:38:50,812 INFO [qpid.server.registry.ApplicationRegistry] Shutting down ApplicationRegistry:org.apache.qpid.server.registry.configurationfileapplicationregis...@2268898 Exception in thread Thread-93 java.lang.OutOfMemoryError: PermGen space Stopping Plugin manager Exception in thread AnonymousIoService-1 java.lang.OutOfMemoryError: PermGen space Stopped Plugin manager Thread-1259 2010-05-18 17:39:08,086 INFO [qpid.message] MESSAGE [Broker(1)] BRK-1005 : Stopped Exception in thread Thread-1259 java.lang.OutOfMemoryError: PermGen space Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2515) Need to be able to set flow control in Java on a per destination level
[ https://issues.apache.org/jira/browse/QPID-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869115#action_12869115 ] Martin Ritchie commented on QPID-2515: -- The Java Broker supports PFC on the 0-91/0-9/0-8 branch using queue arguments: x-qpid-capacity x-qpid-flow-resume-capacity See here: http://qpid.apache.org/use-producer-flow-control.html I'm not sure that reusing these values to configure consumer flow control is the right approach. We should be able to configure the two indepenantly. Once I'm done with the Slow Consumer Detection work I'm scheduled to work on including Producer Flow Control on the 0-10 code path so would be good if we could work together on how these will interact. Need to be able to set flow control in Java on a per destination level -- Key: QPID-2515 URL: https://issues.apache.org/jira/browse/QPID-2515 Project: Qpid Issue Type: Bug Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.7 Currently consumer flow control is set at connection level. It would nice if capacity (in number of messages) could be specified on a per destination basis. We do not support producer side flow control yet, but when we do this should be easily adapted there as well. I propose to include capacity as a link property in the new addressing scheme. -- 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
Re: Destination based flow control and it's affect on session level heuristics
On 18 May 2010 23:08, Rajith Attapattu rajit...@gmail.com wrote: In the JMS client we use the prefetch value in determining two important heuristics in addition to using it for flow control. 1. We use the prefetch value to determine the batch size for message acks. Ex. if ack mode is auto-ack or dups-ok-ack and if unackedCount = prefetch/2 then we flush the acks. The above is done to ensure that the credits doesn't dry up while still not incurring a penalty due to frequent acking. This seems wrong to me. I'm guessing this is only done on the 0-10 code path as AUTO_ACK should ack for every message. A well behaved client in AUTO_ACK mode should not expect to receive redelivered messages if it crashes before it gets to prefech/2. That sounds more like correct behaviour for DUPS_OK. The number of acks we send back are dependent on the protocol support and the ack mode in use. AUTO_ACK needs to ack every message DUPS_OK doesn't need to ack everyone so can use batching if supported. This isn't always possible if another cilent on the same session has not consumed its messages. At least on 0-8/9/91 as Ack Ranges are not available only ALL to this point. CLIENT_ACK and Transacted are very similar. They need only send the acks when acknowledge() or commit() is called. Transacted has the added ability to send the acks in the DUPS_OK style to reduce the acking burden at the commit() barrier. Either way credit should not be given until the acknowledge() or commit() is performed. Sure this leads to starvation issues but that is the point of prefetch limits. 2. In transacted mode we use the prefetch value to determine if we need to send completions to ensure that credits don't dry up. Or else applications could potentially endup in a deadlock if prefetch was incorrectly configured. Ex. Prefetch is set at 10, but the application logic maybe waiting for some control message to commit, but that message may not be in the first 10 messages. Perhaps my 0-10 spec is rusty but are control messages also flow controlled using prefetch? This doesn't seem right. Prefetch should just be the number of client messages excluding any AMQP control. If the client has misconfigured their app and drys up sitting on a receive() then that is correct behaviour. The broker needs to protect itself from a client asking it to hold on to a large transaction set. However the above situation becomes a bit complicated when we introduce per destination flow control (QPID-2515) as the above are determined at session level. (Perhaps the proper solution here is per session flow control, instead of per destination ? ) Isn't per session what we have now? The 0-8/9/91 Java broker operates prefetch on a per JMS Session basis. Therefore when capacity is specified at the destination level (which overrides the connection default) the above calculations may cause undesired behaviour. Possible solutions that comes to mind, 1. We allow these two heuristics to be explicitly configured. Ex qpid.ack-batch-size and qpid.tx-ack-batch-size. Pros: This may allow the application developer/admin to tune the client based on the applications behaviour. Cons: If the application deviates from the predicted behaviour this could affect performance or worse. 2. We use some sort of mathematical formula that will use the capacity specified in the destinations of the consumers attached to that session, to determine the batch sizes. Pros: Puts less burden on the end users Cons: Creating such a formula may not be straightforward. Your comments and suggestions are most appreciated ! Limiting the consumer on a per destination basis would work but I don't that this would impact flow control. Speaking from a 0-8/9/91 Java broker pov a consuming session is only flow controlled when using NO_ACK mode and it is the client that tells the broker to stop sending. The Producer Flow Control also uses flow control to stop publication from the client but this is on the producing side of the session. I would have thought that a prefetch limit per destination per consumer would be controlled by the broker and the configuration it was given when the consumer started. This is how the Java broker currently performs prefetch. Recording the number of messages sent per session and stopping when credit is exhausted. There is no flow control frames sent to indicate this, the broker just stops. I don't think we need complex heuristics I'd just go with a our current prefetch applying to the session and let developers configure a per destination per consumer limit in addition. Arguably we should through an exception if we try and create consumers whose destination prefetch totals more than their underlying session. Thoughts Martin Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project:
Re: Destination based flow control and it's affect on session level heuristics
On Wed, May 19, 2010 at 9:16 AM, Martin Ritchie ritch...@apache.org wrote: On 18 May 2010 23:08, Rajith Attapattu rajit...@gmail.com wrote: In the JMS client we use the prefetch value in determining two important heuristics in addition to using it for flow control. 1. We use the prefetch value to determine the batch size for message acks. Ex. if ack mode is auto-ack or dups-ok-ack and if unackedCount = prefetch/2 then we flush the acks. The above is done to ensure that the credits doesn't dry up while still not incurring a penalty due to frequent acking. This seems wrong to me. I'm guessing this is only done on the 0-10 code path as AUTO_ACK should ack for every message. A well behaved client in AUTO_ACK mode should not expect to receive redelivered messages if it crashes before it gets to prefech/2. That sounds more like correct behaviour for DUPS_OK. For folks you want the correct behaviour for AUTO_ACK can use -Dqpid.sync_ack=true or sync_ack=true in the connection URL. That will ensure we ack after every message. The number of acks we send back are dependent on the protocol support and the ack mode in use. AUTO_ACK needs to ack every message DUPS_OK doesn't need to ack everyone so can use batching if supported. This isn't always possible if another cilent on the same session has not consumed its messages. At least on 0-8/9/91 as Ack Ranges are not available only ALL to this point. CLIENT_ACK and Transacted are very similar. They need only send the acks when acknowledge() or commit() is called. Transacted has the added ability to send the acks in the DUPS_OK style to reduce the acking burden at the commit() barrier. Either way credit should not be given until the acknowledge() or commit() is performed. Sure this leads to starvation issues but that is the point of prefetch limits. 2. In transacted mode we use the prefetch value to determine if we need to send completions to ensure that credits don't dry up. Or else applications could potentially endup in a deadlock if prefetch was incorrectly configured. Ex. Prefetch is set at 10, but the application logic maybe waiting for some control message to commit, but that message may not be in the first 10 messages. Perhaps my 0-10 spec is rusty but are control messages also flow controlled using prefetch? This doesn't seem right. Prefetch should just be the number of client messages excluding any AMQP control. Sorry for not being clear. I wasn't referring to any AMQP control message. I was talking about an application level control message. Ex when sending a large order, the application may send 4 JMS messages that contains the order and the 5th JMS message may contain something in the body that says end-of-order. If the client has misconfigured their app and drys up sitting on a receive() then that is correct behaviour. The broker needs to protect itself from a client asking it to hold on to a large transaction set. Currently both brokers will not be able to protect itself from large tx sets as it allow us to set any value for flow control. So even if we don't send completions in the middle of the transaction it could still happen, if the prefetch is sufficiently large. So if the client racks up a large transaction set, the broker is unable to do anything, unless we implement some broker limit, just like we have queue limits etc.. However the above situation becomes a bit complicated when we introduce per destination flow control (QPID-2515) as the above are determined at session level. (Perhaps the proper solution here is per session flow control, instead of per destination ? ) Isn't per session what we have now? The 0-8/9/91 Java broker operates prefetch on a per JMS Session basis. Well not in 0-10. Flow control is set on per subscription basis (isn't it per destination?). So if a given session has 2 consumers and the max-prefetch=10. Then the session will have 20 messages. Therefore when capacity is specified at the destination level (which overrides the connection default) the above calculations may cause undesired behaviour. Possible solutions that comes to mind, 1. We allow these two heuristics to be explicitly configured. Ex qpid.ack-batch-size and qpid.tx-ack-batch-size. Pros: This may allow the application developer/admin to tune the client based on the applications behaviour. Cons: If the application deviates from the predicted behaviour this could affect performance or worse. 2. We use some sort of mathematical formula that will use the capacity specified in the destinations of the consumers attached to that session, to determine the batch sizes. Pros: Puts less burden on the end users Cons: Creating such a formula may not be straightforward. Your comments and suggestions are most appreciated ! Limiting the consumer on a per destination basis would work but I don't that this would impact flow control. Speaking from a 0-8/9/91 Java broker
[jira] Updated: (QPID-2581) Create a ConfigurationManager to allow plugins to provide configuration handling classes
[ https://issues.apache.org/jira/browse/QPID-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2581: - Attachment: (was: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch) Create a ConfigurationManager to allow plugins to provide configuration handling classes Key: QPID-2581 URL: https://issues.apache.org/jira/browse/QPID-2581 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 To allow plugins to handle configuration add a ConfigurationManager that will load ConfigurationPlugins during the configuration process before the broker starts up. This will allow the configuration values to be processed and determined to be valid input before we actually attempt to continue broker startup. -- 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-2581) Create a ConfigurationManager to allow plugins to provide configuration handling classes
[ https://issues.apache.org/jira/browse/QPID-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2581: - Attachment: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch Fixed Create a ConfigurationManager to allow plugins to provide configuration handling classes Key: QPID-2581 URL: https://issues.apache.org/jira/browse/QPID-2581 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch To allow plugins to handle configuration add a ConfigurationManager that will load ConfigurationPlugins during the configuration process before the broker starts up. This will allow the configuration values to be processed and determined to be valid input before we actually attempt to continue broker startup. -- 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
Re: [Java] Slow consumer test running out of memory
I had modified the test log4j configuration previously to stop it outputing that specific logging, it seems to be back though - some class name changes altering the Logger name used perhaps ? On 19 May 2010 13:32, Martin Ritchie ritch...@apache.org wrote: Hi Rajith, I think this is actually down to the erroneous adjustment of the ExpiredMessageTask frequency in the NullApplicationRegistry. I recent change I made was to cause HouseKeepingTasks to log when they execute. The NAR though sets the run frequency to every 200ms. This was done for one test. Which test I don't recall right now but will track it down and ensure that it sets the configuration it needs without breaking the other tests. The OOM will be due to the test framework holding on to all the broker log messages. I actually haven't seen a OOM locally on any of my full suite test runs (default,java,java.0.10) but hopefully the change to the housekeeping frequency will address this in your test env. In the mean time I beleive uping the memory avalable to ant will address this. Cheers Martin On 19 May 2010 00:09, Rajith Attapattu rajit...@gmail.com wrote: Hi Martin, The slow consumer test seems to run out of memory. Could you perhaps adjust the test or the memory requirements to ensure it doesn't go OOM ? test: [echo] Using profile:default [junit] Running org.apache.qpid.systest.SlowConsumerTest test:ExpiredMessagesTask 2010-05-18 17:38:48,908 DEBUG [qpid.server.virtualhost.VirtualHostImpl$1ExpiredMessagesTask] Checking message status for queue: ping development:ExpiredMessagesTask 2010-05-18 17:38:48,909 DEBUG [qpid.server.virtualhost.VirtualHostImpl$1ExpiredMessagesTask] Checking message status for queue: ping java.lang.OutOfMemoryError: PermGen space PermGen space Thread-1259 2010-05-18 17:38:50,812 INFO [qpid.server.registry.ApplicationRegistry] Shutting down ApplicationRegistry(1):org.apache.qpid.server.registry.configurationfileapplicationregis...@2268898 Thread-1259 2010-05-18 17:38:50,812 INFO [qpid.server.registry.ApplicationRegistry] Shutting down ApplicationRegistry:org.apache.qpid.server.registry.configurationfileapplicationregis...@2268898 Exception in thread Thread-93 java.lang.OutOfMemoryError: PermGen space Stopping Plugin manager Exception in thread AnonymousIoService-1 java.lang.OutOfMemoryError: PermGen space Stopped Plugin manager Thread-1259 2010-05-18 17:39:08,086 INFO [qpid.message] MESSAGE [Broker(1)] BRK-1005 : Stopped Exception in thread Thread-1259 java.lang.OutOfMemoryError: PermGen space Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2618) Add org.apache.common to the PluginManager exported packages
Add org.apache.common to the PluginManager exported packages Key: QPID-2618 URL: https://issues.apache.org/jira/browse/QPID-2618 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Fix For: 0.7 Adding this package to the PluginManager allows accessing QpidProperties. -- 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-2618) Add org.apache.common to the PluginManager exported packages
[ https://issues.apache.org/jira/browse/QPID-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sorin Suciu updated QPID-2618: -- Attachment: 0001-Added-org.apache.qpid.common-package-to-PluginManage.patch Add org.apache.common to the PluginManager exported packages Key: QPID-2618 URL: https://issues.apache.org/jira/browse/QPID-2618 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Fix For: 0.7 Attachments: 0001-Added-org.apache.qpid.common-package-to-PluginManage.patch Adding this package to the PluginManager allows accessing QpidProperties. -- 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
Re: Destination based flow control and it's affect on session level heuristics
On 19 May 2010 14:36, Rajith Attapattu rajit...@gmail.com wrote: On Wed, May 19, 2010 at 9:16 AM, Martin Ritchie ritch...@apache.org wrote: On 18 May 2010 23:08, Rajith Attapattu rajit...@gmail.com wrote: In the JMS client we use the prefetch value in determining two important heuristics in addition to using it for flow control. 1. We use the prefetch value to determine the batch size for message acks. Ex. if ack mode is auto-ack or dups-ok-ack and if unackedCount = prefetch/2 then we flush the acks. The above is done to ensure that the credits doesn't dry up while still not incurring a penalty due to frequent acking. This seems wrong to me. I'm guessing this is only done on the 0-10 code path as AUTO_ACK should ack for every message. A well behaved client in AUTO_ACK mode should not expect to receive redelivered messages if it crashes before it gets to prefech/2. That sounds more like correct behaviour for DUPS_OK. For folks you want the correct behaviour for AUTO_ACK can use -Dqpid.sync_ack=true or sync_ack=true in the connection URL. That will ensure we ack after every message. Really? The correct behaviour for AUTO_ACK is not the default! That is surely The number of acks we send back are dependent on the protocol support and the ack mode in use. AUTO_ACK needs to ack every message DUPS_OK doesn't need to ack everyone so can use batching if supported. This isn't always possible if another cilent on the same session has not consumed its messages. At least on 0-8/9/91 as Ack Ranges are not available only ALL to this point. CLIENT_ACK and Transacted are very similar. They need only send the acks when acknowledge() or commit() is called. Transacted has the added ability to send the acks in the DUPS_OK style to reduce the acking burden at the commit() barrier. Either way credit should not be given until the acknowledge() or commit() is performed. Sure this leads to starvation issues but that is the point of prefetch limits. 2. In transacted mode we use the prefetch value to determine if we need to send completions to ensure that credits don't dry up. Or else applications could potentially endup in a deadlock if prefetch was incorrectly configured. Ex. Prefetch is set at 10, but the application logic maybe waiting for some control message to commit, but that message may not be in the first 10 messages. Perhaps my 0-10 spec is rusty but are control messages also flow controlled using prefetch? This doesn't seem right. Prefetch should just be the number of client messages excluding any AMQP control. Sorry for not being clear. I wasn't referring to any AMQP control message. I was talking about an application level control message. Ex when sending a large order, the application may send 4 JMS messages that contains the order and the 5th JMS message may contain something in the body that says end-of-order. That is an application error though and not something we should be trying to solve. They may have forgotten to send the end-of-order message. Does that mean we have to keep expanding our prefetch window to allow their app to work? If the client has misconfigured their app and drys up sitting on a receive() then that is correct behaviour. The broker needs to protect itself from a client asking it to hold on to a large transaction set. Currently both brokers will not be able to protect itself from large tx sets as it allow us to set any value for flow control. So even if we don't send completions in the middle of the transaction it could still happen, if the prefetch is sufficiently large. So if the client racks up a large transaction set, the broker is unable to do anything, unless we implement some broker limit, just like we have queue limits etc.. Sure you can always configure your application to break the broker. We just don't make the broker to say no you can't have that prefetch size. Which really we should. However sending completions in the middle of the transaction means you can consume MORE then the prefetch. Does the completion just restore credit. I assume that the ack isn't actually processed and still remains part of the transaction. i.e. if the app falls over after the completion those messages will come back. However the above situation becomes a bit complicated when we introduce per destination flow control (QPID-2515) as the above are determined at session level. (Perhaps the proper solution here is per session flow control, instead of per destination ? ) Isn't per session what we have now? The 0-8/9/91 Java broker operates prefetch on a per JMS Session basis. Well not in 0-10. Flow control is set on per subscription basis (isn't it per destination?). So if a given session has 2 consumers and the max-prefetch=10. Then the session will have 20 messages. That makes sense and would be very easy to add to the 0-8/9/91 code path. It is rather unfortunate that we used the same property as one pertains to
Re: Destination based flow control and it's affect on session level heuristics
On Wed, May 19, 2010 at 10:32 AM, Martin Ritchie ritch...@apache.org wrote: On 19 May 2010 14:36, Rajith Attapattu rajit...@gmail.com wrote: On Wed, May 19, 2010 at 9:16 AM, Martin Ritchie ritch...@apache.org wrote: On 18 May 2010 23:08, Rajith Attapattu rajit...@gmail.com wrote: In the JMS client we use the prefetch value in determining two important heuristics in addition to using it for flow control. 1. We use the prefetch value to determine the batch size for message acks. Ex. if ack mode is auto-ack or dups-ok-ack and if unackedCount = prefetch/2 then we flush the acks. The above is done to ensure that the credits doesn't dry up while still not incurring a penalty due to frequent acking. This seems wrong to me. I'm guessing this is only done on the 0-10 code path as AUTO_ACK should ack for every message. A well behaved client in AUTO_ACK mode should not expect to receive redelivered messages if it crashes before it gets to prefech/2. That sounds more like correct behaviour for DUPS_OK. For folks you want the correct behaviour for AUTO_ACK can use -Dqpid.sync_ack=true or sync_ack=true in the connection URL. That will ensure we ack after every message. Really? The correct behaviour for AUTO_ACK is not the default! That is surely Setting sync-ack=true degrades the performance by an order of magnitude :) The number of acks we send back are dependent on the protocol support and the ack mode in use. AUTO_ACK needs to ack every message DUPS_OK doesn't need to ack everyone so can use batching if supported. This isn't always possible if another cilent on the same session has not consumed its messages. At least on 0-8/9/91 as Ack Ranges are not available only ALL to this point. CLIENT_ACK and Transacted are very similar. They need only send the acks when acknowledge() or commit() is called. Transacted has the added ability to send the acks in the DUPS_OK style to reduce the acking burden at the commit() barrier. Either way credit should not be given until the acknowledge() or commit() is performed. Sure this leads to starvation issues but that is the point of prefetch limits. 2. In transacted mode we use the prefetch value to determine if we need to send completions to ensure that credits don't dry up. Or else applications could potentially endup in a deadlock if prefetch was incorrectly configured. Ex. Prefetch is set at 10, but the application logic maybe waiting for some control message to commit, but that message may not be in the first 10 messages. Perhaps my 0-10 spec is rusty but are control messages also flow controlled using prefetch? This doesn't seem right. Prefetch should just be the number of client messages excluding any AMQP control. Sorry for not being clear. I wasn't referring to any AMQP control message. I was talking about an application level control message. Ex when sending a large order, the application may send 4 JMS messages that contains the order and the 5th JMS message may contain something in the body that says end-of-order. That is an application error though and not something we should be trying to solve. They may have forgotten to send the end-of-order message. Does that mean we have to keep expanding our prefetch window to allow their app to work? Good point. But I think my original example was bad, hence I sent you down the wrong direction. I apologize for that. Here is a better use case Consider a prefetch of 1 (which is the same as no prefetch) In that case we **really** need to ack unless we are doing transactions with size = 1. Or else we will just wait indefinitely for messages to arrive. So I think this heuristic is really there for, when your transaction size prefetch. And that is a very valid use case, the most prominent being the case of no-prefetch. Hope this explains it better. If the client has misconfigured their app and drys up sitting on a receive() then that is correct behaviour. The broker needs to protect itself from a client asking it to hold on to a large transaction set. Currently both brokers will not be able to protect itself from large tx sets as it allow us to set any value for flow control. So even if we don't send completions in the middle of the transaction it could still happen, if the prefetch is sufficiently large. So if the client racks up a large transaction set, the broker is unable to do anything, unless we implement some broker limit, just like we have queue limits etc.. Sure you can always configure your application to break the broker. We just don't make the broker to say no you can't have that prefetch size. Which really we should. However sending completions in the middle of the transaction means you can consume MORE then the prefetch. Does the completion just restore credit. I assume that the ack isn't actually processed and still remains part of the transaction. i.e. if the app falls over after the completion those messages will come
Re: Destination based flow control and it's affect on session level heuristics
On 05/19/2010 02:36 PM, Rajith Attapattu wrote: On Wed, May 19, 2010 at 9:16 AM, Martin Ritchieritch...@apache.org wrote: The 0-8/9/91 Java broker operates prefetch on a per JMS Session basis. Well not in 0-10. This seems to be at the heart of your issue; prefetch is not unambiguously defined and means different things to different people or on different versions of the protocol where the flow control mechanisms are different. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: (was: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch) Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: (was: 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch) Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2581) Create a ConfigurationManager to allow plugins to provide configuration handling classes
[ https://issues.apache.org/jira/browse/QPID-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2581: - Attachment: (was: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch) Create a ConfigurationManager to allow plugins to provide configuration handling classes Key: QPID-2581 URL: https://issues.apache.org/jira/browse/QPID-2581 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch To allow plugins to handle configuration add a ConfigurationManager that will load ConfigurationPlugins during the configuration process before the broker starts up. This will allow the configuration values to be processed and determined to be valid input before we actually attempt to continue broker startup. -- 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-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch Changed due to svn rebase Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch, 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2542) Implement ACL checking as OSGi plugin
[ https://issues.apache.org/jira/browse/QPID-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2542: - Attachment: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch Changed due to svn rebase Implement ACL checking as OSGi plugin - Key: QPID-2542 URL: https://issues.apache.org/jira/browse/QPID-2542 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch -- 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-2581) Create a ConfigurationManager to allow plugins to provide configuration handling classes
[ https://issues.apache.org/jira/browse/QPID-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2581: - Attachment: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch Changed due to svn rebase Create a ConfigurationManager to allow plugins to provide configuration handling classes Key: QPID-2581 URL: https://issues.apache.org/jira/browse/QPID-2581 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0002-QPID-2581-Update-configuration-manager-to-allow-mul.patch To allow plugins to handle configuration add a ConfigurationManager that will load ConfigurationPlugins during the configuration process before the broker starts up. This will allow the configuration values to be processed and determined to be valid input before we actually attempt to continue broker startup. -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: (was: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch) Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy -- 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-2542) Implement ACL checking as OSGi plugin
[ https://issues.apache.org/jira/browse/QPID-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2542: - Attachment: (was: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch) Implement ACL checking as OSGi plugin - Key: QPID-2542 URL: https://issues.apache.org/jira/browse/QPID-2542 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch Changed due to svn rebase Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: (was: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch) Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch (missed a file...) Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch -- 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
Re: Destination based flow control and it's affect on session level heuristics
On 19 May 2010 15:47, Rajith Attapattu rajit...@gmail.com wrote: On Wed, May 19, 2010 at 10:32 AM, Martin Ritchie ritch...@apache.org wrote: On 19 May 2010 14:36, Rajith Attapattu rajit...@gmail.com wrote: On Wed, May 19, 2010 at 9:16 AM, Martin Ritchie ritch...@apache.org wrote: On 18 May 2010 23:08, Rajith Attapattu rajit...@gmail.com wrote: In the JMS client we use the prefetch value in determining two important heuristics in addition to using it for flow control. 1. We use the prefetch value to determine the batch size for message acks. Ex. if ack mode is auto-ack or dups-ok-ack and if unackedCount = prefetch/2 then we flush the acks. The above is done to ensure that the credits doesn't dry up while still not incurring a penalty due to frequent acking. This seems wrong to me. I'm guessing this is only done on the 0-10 code path as AUTO_ACK should ack for every message. A well behaved client in AUTO_ACK mode should not expect to receive redelivered messages if it crashes before it gets to prefech/2. That sounds more like correct behaviour for DUPS_OK. For folks you want the correct behaviour for AUTO_ACK can use -Dqpid.sync_ack=true or sync_ack=true in the connection URL. That will ensure we ack after every message. Really? The correct behaviour for AUTO_ACK is not the default! That is surely Setting sync-ack=true degrades the performance by an order of magnitude :) The number of acks we send back are dependent on the protocol support and the ack mode in use. AUTO_ACK needs to ack every message DUPS_OK doesn't need to ack everyone so can use batching if supported. This isn't always possible if another cilent on the same session has not consumed its messages. At least on 0-8/9/91 as Ack Ranges are not available only ALL to this point. CLIENT_ACK and Transacted are very similar. They need only send the acks when acknowledge() or commit() is called. Transacted has the added ability to send the acks in the DUPS_OK style to reduce the acking burden at the commit() barrier. Either way credit should not be given until the acknowledge() or commit() is performed. Sure this leads to starvation issues but that is the point of prefetch limits. 2. In transacted mode we use the prefetch value to determine if we need to send completions to ensure that credits don't dry up. Or else applications could potentially endup in a deadlock if prefetch was incorrectly configured. Ex. Prefetch is set at 10, but the application logic maybe waiting for some control message to commit, but that message may not be in the first 10 messages. Perhaps my 0-10 spec is rusty but are control messages also flow controlled using prefetch? This doesn't seem right. Prefetch should just be the number of client messages excluding any AMQP control. Sorry for not being clear. I wasn't referring to any AMQP control message. I was talking about an application level control message. Ex when sending a large order, the application may send 4 JMS messages that contains the order and the 5th JMS message may contain something in the body that says end-of-order. That is an application error though and not something we should be trying to solve. They may have forgotten to send the end-of-order message. Does that mean we have to keep expanding our prefetch window to allow their app to work? Good point. But I think my original example was bad, hence I sent you down the wrong direction. I apologize for that. Here is a better use case Consider a prefetch of 1 (which is the same as no prefetch) In that case we **really** need to ack unless we are doing transactions with size = 1. Or else we will just wait indefinitely for messages to arrive. Perhaps the problem is what people believe prefetch is doing. For me setting perfetch is setting the maximum number of resources you will need. So if you set prefetch to 1 and expect two messages before the commit then your app is flawed. So I think this heuristic is really there for, when your transaction size prefetch. And that is a very valid use case, the most prominent being the case of no-prefetch. 0-8/9/91 doesn't currently have an option to disable prefetch (disable is not prefetch=0) and so therefore have an unbounded resource usage on the broker. if transaction size prefetch then I would always say that is the app's fault. If we want to support unbounded resources limits then we need to signal that to the broker but also have some way of preventing it sending everything to our client and overwhelming it. In that scenario the what we are doing as you say is asking for more messages not acking the ones we have received. This is very similar to what the 0-8/9/91 code path does in NO_ACK. The the broker is told to send all messages to the client and the client flow controls the broker to say stop I've got enough just now. Hope this explains it better. Think we are getting there :) If the client has misconfigured
Re: Destination based flow control and it's affect on session level heuristics
On 19 May 2010 15:55, Gordon Sim g...@redhat.com wrote: On 05/19/2010 02:36 PM, Rajith Attapattu wrote: On Wed, May 19, 2010 at 9:16 AM, Martin Ritchieritch...@apache.org wrote: The 0-8/9/91 Java broker operates prefetch on a per JMS Session basis. Well not in 0-10. This seems to be at the heart of your issue; prefetch is not unambiguously defined and means different things to different people or on different versions of the protocol where the flow control mechanisms are different. Agreed, perhaps having the one property 'max_prefetch' really isn't enough to explain how it should be used. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: (was: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch) Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2585) Upgrade Felix to 2.0.5
[ https://issues.apache.org/jira/browse/QPID-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2585: - Attachment: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch Added another exported package Upgrade Felix to 2.0.5 -- Key: QPID-2585 URL: https://issues.apache.org/jira/browse/QPID-2585 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Attachments: 0009-QPID-2585-Upgrade-Felix-to-2.0.5.patch, 0013-QPID-2585-Update-extras-OSGi-plugin-to-work-with-la.patch Felix 1.0 has a number of issues that prevent us using as our OSGi manager, upgrading to the latest 2.0.5 will address these issues. -- 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-2542) Implement ACL checking as OSGi plugin
[ https://issues.apache.org/jira/browse/QPID-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2542: - Attachment: (was: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch) Implement ACL checking as OSGi plugin - Key: QPID-2542 URL: https://issues.apache.org/jira/browse/QPID-2542 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0011-QPID-2542-Implement-ACL-checking-as-OSGi-plugin.patch -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: (was: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch) Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy -- 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-2606) Clarify/identify where ACL permission should be applied in the broker
[ https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2606: - Attachment: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch Improved handling of enqueue events (publishing) Clarify/identify where ACL permission should be applied in the broker -- Key: QPID-2606 URL: https://issues.apache.org/jira/browse/QPID-2606 Project: Qpid Issue Type: Sub-task Reporter: Andrew Kennedy Attachments: 0010-QPID-2606-Identify-where-ACL-permission-should-be-a.patch -- 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-2466) Replace WeakReference use with SoftReference for enhanced message caching
[ https://issues.apache.org/jira/browse/QPID-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2466: - Status: Ready To Review (was: In Progress) Replace WeakReference use with SoftReference for enhanced message caching - Key: QPID-2466 URL: https://issues.apache.org/jira/browse/QPID-2466 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.6 Environment: JVM 1.6.0_18 Reporter: Andrew Kennedy Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2466-Replace-WeakReference-use-with-SoftRefere.patch, 0001-QPID-2466-trunk.patch Replace use of WeakReference with SoftReference in the message handles in the broker to improve message cache performance when using a persistent store. Also tuning the eviction policy for soft references and evaluation of other GC settings. -- 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
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 18 May 2010 14:52, Rajith Attapattu rajit...@gmail.com wrote:
Andrew, I have added your proposal and the text you pasted here in
https://cwiki.apache.org/confluence/display/qpid/andrew+acl+proposal
This page is linked off,
https://cwiki.apache.org/confluence/display/qpid/ACL+Design
And the above is linked off the developer pages.
I will get out my proposal a bit later in the week.
Thanks.
For completeness, I have tried to put together another page covering
the recent discussion on the 'METHOD' object and management
operations, the text of which is attached below. Rajith, could you
stick it in another wiki page, please? I think this is a useful
compromise, although there may be some further work required to
straighten out the QMF and JMX bindings anyway...
h1. Method Redux
_Though this be madness, yet there is method in't._
*Polonius, Hamlet Act 2, scene 2*
h2. Introduction
The main point of contention in the ACL debate seems to centre around
the mechanism used to permission non AMQP entities, the current
_METHOD_ method is felt to be unsuitable. This document proposes an
update to this syntax and describes exactly how it should be
interpreted across brokers.
h2. Access Control
The things that are being controlled or permissioned by entries in the
access control list are objects that form part of the Qpid broker.
These entities could reasonably be said to be _children_ of the
broker, although I don't feel that a tree-type structure is either
helpful or necessary here, since there is no parallel in the Qpid or
AMQP internals. A flat _object type_ space has therefore been assumed,
continuing current behavior. These types of object have until now
simply represented the major types of object that exist and are
manipulable inside a broker. The only addition is that of the broker
itself, since there are some operations and actions that can only
realistically be said to be performed globally. This is the rationale
behind such proposed ACL entries as:
{noformat}
ACL ALLOW robot ACCESS LOG
ACL DENY robot UPDATE CONFIG
ACL DENY kitten UPDATE USERS
ACL ALLOW kitten ADMIN LOG
{noformat}
The _LOG_, _CONFIG_ and _USERS_ object types here represent subsystems
or components or simply collections of management methods that perform
a similar set of tasks. They are *not* actual broker objects, although
(see later) they may be QMF classes, with their own management schema
and package.
A different approach to access control for these management methods
relies on the _BROKER_ object type being used for permissioning,
giving rise to ACL entries as follows:
{noformat}
ACL DENY robot ACCESS BROKER
ACL DENY kitten UPDATE BROKER subsystem=logging
ACL ALLOW kitten ACCESS BROKER method=get*
ACL ALLOW kitten ACCESS BROKER method=invoke*
ACL ALLOW kitten MANAGE BROKER subsystem=users
{noformat}
This _BROKER_ object type represents the entire runtime entity, and is
in fact represented in the QMF management schema, with properties,
statistics and methods available. This is not meant to indicate a
preference for QMF as a final reference point, it should be noted,
rather this is illustrative of the sorts of entities an access control
object type could map to.
{noformat}
class name=Broker
property name=name /
property name=systemRef /
property name=port /
/class
{noformat}
h3. Existing Syntax
The previous ACL entries would all be permissioned using the _METHOD_
object type in the current C++ broker, assuming a logical extension of
the existing syntax. The problem with this syntax is that it is very
closely coupled to the management framework, QMF. Also, the
granularity of the controls falls awkwardly between extremes, and
requires too much specificity to enumerate all methods dealing with a
particular area of interest when controlling that type of access, and
not distinguishing between *getName* methods on various different
managed objects. This makes it impossible to correctly permission
access to multiple objects with similarly named methods. Also, since
JMX provides access to properties using a method call, a permission
for that method would need to be created to allow _READ_ access to a
property, which blurs the distiction between methods and properties.
h3. Mechanism versus Meaning
Since the current C++ implementation is based exclusively on QMF, only
features supported and used by QMF are available. It is preferable to
have a mechanism-agnostic access control specification, since QMF and
JMX will not be the only management entry-points for ever, with SNMP
and other industry standards available as well as future JEE
development. Also, it should be possible to permission access in a
manner that does not depend on the version of the QMF schema or API,
depending only on the existence or not of particular manageable
objects within the broker. This means that when a new method or
attribute is added at an API change, or a method name is changed,
existing ACLS will have the same meaning as before.
[jira] Created: (QPID-2619) Capture the PID for the qpid broker on unix platforms
Capture the PID for the qpid broker on unix platforms - Key: QPID-2619 URL: https://issues.apache.org/jira/browse/QPID-2619 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 As of now we are not capturing the pid for the qpid process upon start. This can be useful for monitoring purposes. -- 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
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
I've had a brief read, it seem seems the point I was trying to make has
been entirely miss-understood.
How about some IRC, or a call if you can do that and the reflect back to
the list.
Carl.
On 05/19/2010 11:59 AM, Andrew Kennedy wrote:
On 18 May 2010 14:52, Rajith Attapatturajit...@gmail.com wrote:
Andrew, I have added your proposal and the text you pasted here in
https://cwiki.apache.org/confluence/display/qpid/andrew+acl+proposal
This page is linked off,
https://cwiki.apache.org/confluence/display/qpid/ACL+Design
And the above is linked off the developer pages.
I will get out my proposal a bit later in the week.
Thanks.
For completeness, I have tried to put together another page covering
the recent discussion on the 'METHOD' object and management
operations, the text of which is attached below. Rajith, could you
stick it in another wiki page, please? I think this is a useful
compromise, although there may be some further work required to
straighten out the QMF and JMX bindings anyway...
h1. Method Redux
_Though this be madness, yet there is method in't._
*Polonius, Hamlet Act 2, scene 2*
h2. Introduction
The main point of contention in the ACL debate seems to centre around
the mechanism used to permission non AMQP entities, the current
_METHOD_ method is felt to be unsuitable. This document proposes an
update to this syntax and describes exactly how it should be
interpreted across brokers.
h2. Access Control
The things that are being controlled or permissioned by entries in the
access control list are objects that form part of the Qpid broker.
These entities could reasonably be said to be _children_ of the
broker, although I don't feel that a tree-type structure is either
helpful or necessary here, since there is no parallel in the Qpid or
AMQP internals. A flat _object type_ space has therefore been assumed,
continuing current behavior. These types of object have until now
simply represented the major types of object that exist and are
manipulable inside a broker. The only addition is that of the broker
itself, since there are some operations and actions that can only
realistically be said to be performed globally. This is the rationale
behind such proposed ACL entries as:
{noformat}
ACL ALLOW robot ACCESS LOG
ACL DENY robot UPDATE CONFIG
ACL DENY kitten UPDATE USERS
ACL ALLOW kitten ADMIN LOG
{noformat}
The _LOG_, _CONFIG_ and _USERS_ object types here represent subsystems
or components or simply collections of management methods that perform
a similar set of tasks. They are *not* actual broker objects, although
(see later) they may be QMF classes, with their own management schema
and package.
A different approach to access control for these management methods
relies on the _BROKER_ object type being used for permissioning,
giving rise to ACL entries as follows:
{noformat}
ACL DENY robot ACCESS BROKER
ACL DENY kitten UPDATE BROKER subsystem=logging
ACL ALLOW kitten ACCESS BROKER method=get*
ACL ALLOW kitten ACCESS BROKER method=invoke*
ACL ALLOW kitten MANAGE BROKER subsystem=users
{noformat}
This _BROKER_ object type represents the entire runtime entity, and is
in fact represented in the QMF management schema, with properties,
statistics and methods available. This is not meant to indicate a
preference for QMF as a final reference point, it should be noted,
rather this is illustrative of the sorts of entities an access control
object type could map to.
{noformat}
class name=Broker
property name=name /
property name=systemRef /
property name=port /
/class
{noformat}
h3. Existing Syntax
The previous ACL entries would all be permissioned using the _METHOD_
object type in the current C++ broker, assuming a logical extension of
the existing syntax. The problem with this syntax is that it is very
closely coupled to the management framework, QMF. Also, the
granularity of the controls falls awkwardly between extremes, and
requires too much specificity to enumerate all methods dealing with a
particular area of interest when controlling that type of access, and
not distinguishing between *getName* methods on various different
managed objects. This makes it impossible to correctly permission
access to multiple objects with similarly named methods. Also, since
JMX provides access to properties using a method call, a permission
for that method would need to be created to allow _READ_ access to a
property, which blurs the distiction between methods and properties.
h3. Mechanism versus Meaning
Since the current C++ implementation is based exclusively on QMF, only
features supported and used by QMF are available. It is preferable to
have a mechanism-agnostic access control specification, since QMF and
JMX will not be the only management entry-points for ever, with SNMP
and other industry standards available as well as future JEE
development. Also, it should be possible to permission access in a
manner that does not depend on the version of the QMF schema
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 19 May 2010 17:22, Carl Trieloff cctriel...@redhat.com wrote: I've had a brief read, it seem seems the point I was trying to make has been entirely miss-understood. How about some IRC, or a call if you can do that and the reflect back to the list. Carl. Carl, I'm off home just now, but maybe if we have a chat tomorrow when you're free? I would like to get this cleared up, because it seems like a simple little thing and it shouldn't hold up progress. What I'd like to get agreed on is a mechanism for permissioning the management entry-points of the broker. I don't have IRC access, so can you reply to this with a number and time I can get you on, and maybe we can come up with a solution to post to the list tomorrow? Cheers, Andrew. -- -- andrew d kennedy ? edinburgh : +44 7941 197 134 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2620) Enable the Java Broker to run as a service on Windows platforms
Enable the Java Broker to run as a service on Windows platforms --- Key: QPID-2620 URL: https://issues.apache.org/jira/browse/QPID-2620 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 It seems to be useful for Windows users to have qpid run as a service. -- 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
Re: Multiple topics per queue with the JMS API
Le 17/05/2010 19:33, Rajith Attapattu a écrit : In the future we may have a Java messaging API that is similar to the new C++ and Python API. And then build our JMS layer as a thin layer on top of it. Such a messaging API for Java would be really great. I don't mind if the API is unstable as long as it's close to the AMQP semantic and well supported. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 05/19/2010 12:30 PM, Andrew Kennedy wrote: On 19 May 2010 17:22, Carl Trieloffcctriel...@redhat.com wrote: I've had a brief read, it seem seems the point I was trying to make has been entirely miss-understood. How about some IRC, or a call if you can do that and the reflect back to the list. Carl. Carl, I'm off home just now, but maybe if we have a chat tomorrow when you're free? I would like to get this cleared up, because it seems like a simple little thing and it shouldn't hold up progress. What I'd like to get agreed on is a mechanism for permissioning the management entry-points of the broker. I don't have IRC access, so can you reply to this with a number and time I can get you on, and maybe we can come up with a solution to post to the list tomorrow? Cheers, Andrew. I've sent phone number privately. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Multiple topics per queue with the JMS API
Le 17/05/2010 19:13, Martin Ritchie a écrit : Emmanuel, If you are looking to perform the bind/unbind to an existing queue then there is a bindQueue method on AMQSession however I was just looking at this and noticed there is no unbind. A simple thing to expose, but without a clear approach on exposing AMQP functionality in the java client it may subject to change. Thank you Martin, I looked at AMQSession but it seems my understanding of the code isn't good enough to implement the unbind feature myself. If someone could look into it that would be really nice. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
I see that Qpid does not have a category on the JIRA...
Anyone volunteer to work with infra and fix this, + take over ownership of Qpid JIRA from Cliff. https://issues.apache.org/jira/secure/BrowseProjects.jspa Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
no left navigation panel on qpid website
Hi, It seems we are missing the left navigation panel on qpid website (jira issue?). This makes the access to the right area a bit laborious, is anyone looking to fix this? Thank you, Sorin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
