[jira] Updated: (QPID-2178) Allow viewing of channel flow control status via JMX Management Console
[ https://issues.apache.org/jira/browse/QPID-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2178: - Status: Ready To Review (was: In Progress) Allow viewing of channel flow control status via JMX Management Console --- Key: QPID-2178 URL: https://issues.apache.org/jira/browse/QPID-2178 Project: Qpid Issue Type: New Feature Components: Java Management : JMX Console, Java Management : JMX Interface Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.6 When Flow Control is being utilised on the broker, it may be useful to expose the status of a channel (based on thevalue of _blocking in AMQChannel) as a read-only property via the management console. Channel properties are currently only exposed by the broker over JMX via the ManagedConnection mbean interface which defines a channels() method implemented in the AMQProtocolSessionMBean, that returns a data set consisting of channel id, transactional status, default queue, and number of unacked messages for all channels on the connection. In order to expose the flow controlled status of the channel, this result set would be expanded to include the value of the new _blocking AtomicBoolean within AMQSession. Expanding the result set would not affect compatability with the older console UI, which should automatically display it thanks to its completely generic construction. The new console UI utilises this particular information set quite differently in order to construct a structured table and would not make use of the additional information until modified to do so (its presence would not interfere until that time, it simply wont be utilised) by performing a small update to add a new table column when the additional information is available on supporting brokers. -- 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-2189) only admin level users can complete connection to 2.5.0.0 or below (when configured to use security-enabled / JMXMP)
[ https://issues.apache.org/jira/browse/QPID-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2189: - Status: Ready To Review (was: In Progress) only admin level users can complete connection to 2.5.0.0 or below (when configured to use security-enabled / JMXMP) -- Key: QPID-2189 URL: https://issues.apache.org/jira/browse/QPID-2189 Project: Qpid Issue Type: Bug Components: Java Management : JMX Console Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.6 Only admin level users can complete connection to 2.5.0.0, or older brokers configured to use security-enabled / JMXMP for their management connection. Thisis due to the new console using a fallback method to determine what 'Qpid JMX API' version to classify the broker as supporting. In doing so, the console queries the MbeanServerConnection for the existence of the UserManagement MBean using an exact match for its 'type' key. Whilst other calls to the same queryNames method will return the UserManagement MBean's ObjectName, the broker uses the exact type of this MBean to prevent non-admin users from actually accessing it and so when the query is an exact match is placed in the query this raises a SecurityException and causes the connection to fail. The solution is to change the query to use an ObjectName pattern to match the UserManagement MBean which will still match only the Mbean in question but prevent the security check from denying the request. -- 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-2190) enable the updated jmx management console to connect to very old brokers
[ https://issues.apache.org/jira/browse/QPID-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2190: - Status: Ready To Review (was: In Progress) enable the updated jmx management console to connect to very old brokers Key: QPID-2190 URL: https://issues.apache.org/jira/browse/QPID-2190 Project: Qpid Issue Type: Bug Components: Java Management : JMX Console Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.6 The updated jmx management console uses the UserManagement MBean to classify the management API version when connecting to brokers pre 0.6. The UserManagement MBean was not present in the earliest releases, so to enable full backwards connectivity it should treat the lack of the MBean as meaning an earlier version, instead of failing to complete the connection as present. -- 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: Store tests
Hello! On Wed, Nov 11, 2009 at 02:45:25AM +, James Birdsall wrote: + clicking on the Qpid Testing link gets me a login page, then after I log in I get You cannot view this page, Page level restrictions have been applied that limit access to this page. snip I am experiencing all the same. Thank you, James, for pointing this out! Best regards, Jasan -- Red Hat Czech, MRG Quality Assurance Associate - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Store tests
2009/11/11 Ján Sáreník jsare...@redhat.com: Hello! On Wed, Nov 11, 2009 at 02:45:25AM +, James Birdsall wrote: + clicking on the Qpid Testing link gets me a login page, then after I log in I get You cannot view this page, Page level restrictions have been applied that limit access to this page. snip I am experiencing all the same. Thank you, James, for pointing this out! Best regards, Jasan Should be fixed now. The IBM JMS Testing page is still restricted to qpid-comitters. IIRC this is because we have results from the IBM JMS Toolkit there and the license says not to publish results. -- Red Hat Czech, MRG Quality Assurance Associate - 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-2196) JMX Management Console may try to auto-refresh between recieving notification of JMXConnector failure/closure and the server view actually being closed
[ https://issues.apache.org/jira/browse/QPID-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2196: - Status: Ready To Review (was: In Progress) JMX Management Console may try to auto-refresh between recieving notification of JMXConnector failure/closure and the server view actually being closed Key: QPID-2196 URL: https://issues.apache.org/jira/browse/QPID-2196 Project: Qpid Issue Type: Bug Components: Java Management : JMX Console Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.6 The JMX Management Console may try to auto-refresh the server view between recieving notification of JMXConnector failure/closure, and the server view actually finishing being cleaned up and cleared. This can result in NullPointerException when the console tries using details of an MBean retrieved from a map that can no longer return the required details. This can also lead to failure to properly clean up the connection tree, leaving the defunct server connection in view with the user unable to reconnect to that server without restarting the console. -- 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-2193) Allow deleting the first message on a queue through the JMX Management Console when connected to older brokers
[ https://issues.apache.org/jira/browse/QPID-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776461#action_12776461 ] Robbie Gemmell commented on QPID-2193: -- Ive added a warning note to the confirmation dialog box :) Allow deleting the first message on a queue through the JMX Management Console when connected to older brokers --- Key: QPID-2193 URL: https://issues.apache.org/jira/browse/QPID-2193 Project: Qpid Issue Type: New Feature Components: Java Management : JMX Console Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Minor Fix For: 0.6 Java brokers previous to 0.6 do not support deletion of arbitrary messages, only the 'first message on the queue' at any given time. This was not exposed in the updated console due for release with 0.6 (where the broker now does support deletion of arbitrary messages). This decision was made because by its very nature the method cannot guarantee which message would be deleted when it is executed, as any queue activity could alter which message is at the head of the queue. However, users may have come to expect this method to be present, and so it should be exposed for older brokers that lack the ability to exactly specify which messages should be deleted. -- 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-2193) Allow deleting the first message on a queue through the JMX Management Console when connected to older brokers
[ https://issues.apache.org/jira/browse/QPID-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2193: - Status: Ready To Review (was: In Progress) Allow deleting the first message on a queue through the JMX Management Console when connected to older brokers --- Key: QPID-2193 URL: https://issues.apache.org/jira/browse/QPID-2193 Project: Qpid Issue Type: New Feature Components: Java Management : JMX Console Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Minor Fix For: 0.6 Java brokers previous to 0.6 do not support deletion of arbitrary messages, only the 'first message on the queue' at any given time. This was not exposed in the updated console due for release with 0.6 (where the broker now does support deletion of arbitrary messages). This decision was made because by its very nature the method cannot guarantee which message would be deleted when it is executed, as any queue activity could alter which message is at the head of the queue. However, users may have come to expect this method to be present, and so it should be exposed for older brokers that lack the ability to exactly specify which messages should be deleted. -- 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: xqilla-dev
Thanks Gordon, I did that and other packages was fine. On Tue, Nov 10, 2009 at 8:14 AM, Gordon Sim g...@redhat.com wrote: On 11/07/2009 11:40 AM, Rodrigo K. Ferreira wrote: Hi, I'm trying to compile qpidc on rhel 4, but I stopped at xqilla and xqilla-dev dependencie, anyone have pre-compiled rpms for this ? I don't I'm afraid. Note that you can build without them (you may need to configure --without-xml if you have incompatible versions of those libs). - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
New SASL capability for the Python client
Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This module will be built under the cpp build if the python-devel and swig packages are present on the development system. To use it, your PYTHONPATH must provide access to the following files (or those files need to be copied to where the PYTHONPATH can reach them): $(build_dir)/bindings/sasl/python/qpidsasl.py $(build_dir)/bindings/sasl/.libs/_qpidsasl.so The following library is also built (it contains the C++ implemented SASL wrapper): $(build_dir)/bindings/sasl/.libs/libsaslwrapper.so When creating the Connection object, you may supply the mechanism argument with a space-separated list of acceptable authentication mechanisms. If this argument is left to the default value of None (recommended), the SASL library will pick the best available mechanism for you. For Kerberos5 single-sign-on, the GSSAPI mechanism is used. Some notes/caveats: This is not yet hooked into the newer qpid.messaging API. This is not built under CMake yet. This implementation is specific to Linux/Unix. It is possible that a Windows implementation of the wrapper can be developed. SASL EXTERNAL (i.e. use of SSL/TLS client certificates) is not yet supported. This will be forthcoming. Note also that I intend to add a Ruby binding to this module and move the Ruby client to it. Ruby already has this capability but using the same one that python uses will reduce future support headaches. -Ted - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: New SASL capability for the Python client
On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. For Fedora (and the like you'd package it in packages called python-sasl, ruby-sasl unless those names are already taken) Have I missed something here that makes this actually specific to qpid? Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: New SASL capability for the Python client
On Wed, 2009-11-11 at 16:29 -0500, Andrew Stitcher wrote: On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. Specifically I'd add that its location in the source tree is not correct in my mind - it is not really any part of the c++ implementation of the amqp protocol and it is not a binding to a any qpid library so putting it in cpp/bindings is more confusing than not. It also adds to an already complex c++ build. I'd prefer to see it moved to its own top level directory until we can put it outside qpid altogether. Say in sasl. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: New SASL capability for the Python client
Andrew Stitcher wrote: On Wed, 2009-11-11 at 16:29 -0500, Andrew Stitcher wrote: On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. Specifically I'd add that its location in the source tree is not correct in my mind - it is not really any part of the c++ implementation of the amqp protocol and it is not a binding to a any qpid library so putting it in cpp/bindings is more confusing than not. It also adds to an already complex c++ build. I'd prefer to see it moved to its own top level directory until we can put it outside qpid altogether. Say in sasl. maybe create a util/sasl directory... I would not go to the effort of another package unless there is a LOT of interest to do so Carl.
Re: New SASL capability for the Python client
On 11/11/2009 04:29 PM, Andrew Stitcher wrote: On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. For Fedora (and the like you'd package it in packages called python-sasl, ruby-sasl unless those names are already taken) Have I missed something here that makes this actually specific to qpid? Andrew The library that holds the wrapper code is libsaslwrapper.so. The Python binding I called qpidsasl but you are correct in saying that there is nothing qpid or messaging related in either the library or the module. All the library does is provide an alternate API that doesn't rely on callbacks and is easily wrapped in scripting languages. I'd be happy to move the whole thing to a top level directory under qpid if there's a consensus that that is the right thing to do. I assume that we, as the Qpid community, don't have access to directories above qpid. I just wanted to implement SASL for Python and Ruby, not start a whole new project. -Ted - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2184) updated ip whitelisting / firewall config doesnt take effect after SIGHUP or reloadSecurityConfiguration() JMX method
[ https://issues.apache.org/jira/browse/QPID-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan Skinner resolved QPID-2184. - Resolution: Fixed Fixed in r835115 updated ip whitelisting / firewall config doesnt take effect after SIGHUP or reloadSecurityConfiguration() JMX method - Key: QPID-2184 URL: https://issues.apache.org/jira/browse/QPID-2184 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Aidan Skinner Fix For: 0.6 Attachments: 0001-QPID-2184-add-test-for-reloading-firewall-config-in.patch, 0002-QPID-2184-add-a-test-case-for-the-firewall-config-u.patch updated ip whitelisting / firewall config doesnt take effect after SIGHUP or reloadSecurityConfiguration() via JMX. Changing an existing rule or adding a new rule to reverse the current allow/deny behaviour against a particular client machine does not take effect against new client connections, depsite the SIGHUP / JMX invoked security configuration reload occurring and completing without any Exceptions. Restarting the broker with the updated configuration in place results in the expected behaviour being attained. -- 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
