[jira] Assigned: (QPID-1986) lib jars moved to wrong location for client and broker binary releases
[ https://issues.apache.org/jira/browse/QPID-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-1986: Assignee: Martin Ritchie lib jars moved to wrong location for client and broker binary releases --- Key: QPID-1986 URL: https://issues.apache.org/jira/browse/QPID-1986 Project: Qpid Issue Type: Bug Components: Ant Build System, Java Broker, Java Client Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Martin Ritchie Fix For: 0.6 When running ant with the 'release-bin' target to generate the client and broker (and JMX MC) binary release archives in java/client/release and java/broker/release, the lib jars are incorrectly put in the root of the package directory instead of in the lib/ sub-directory. -- 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-1986) lib jars moved to wrong location for client and broker binary releases
[ https://issues.apache.org/jira/browse/QPID-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1986: - Status: Ready To Review (was: In Progress) lib jars moved to wrong location for client and broker binary releases --- Key: QPID-1986 URL: https://issues.apache.org/jira/browse/QPID-1986 Project: Qpid Issue Type: Bug Components: Ant Build System, Java Broker, Java Client Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Martin Ritchie Fix For: 0.6 When running ant with the 'release-bin' target to generate the client and broker (and JMX MC) binary release archives in java/client/release and java/broker/release, the lib jars are incorrectly put in the root of the package directory instead of in the lib/ sub-directory. -- 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] Assigned: (QPID-1986) lib jars moved to wrong location for client and broker binary releases
[ https://issues.apache.org/jira/browse/QPID-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-1986: Assignee: Robbie Gemmell (was: Martin Ritchie) Hi Robbie, I've applied a fix to trunk for this can you confirm it resolves the issue for you. lib jars moved to wrong location for client and broker binary releases --- Key: QPID-1986 URL: https://issues.apache.org/jira/browse/QPID-1986 Project: Qpid Issue Type: Bug Components: Ant Build System, Java Broker, Java Client Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.6 When running ant with the 'release-bin' target to generate the client and broker (and JMX MC) binary release archives in java/client/release and java/broker/release, the lib jars are incorrectly put in the root of the package directory instead of in the lib/ sub-directory. -- 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-1980) Java broker does not parse protection I/O configuration with expected XML structure
[ https://issues.apache.org/jira/browse/QPID-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734068#action_12734068 ] Martin Ritchie commented on QPID-1980: -- Hi Keith thanks for the patch. Are you using ProtectIO? Would be good to get your experiences of using it. Regards Martin Java broker does not parse protection I/O configuration with expected XML structure --- Key: QPID-1980 URL: https://issues.apache.org/jira/browse/QPID-1980 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.5 Reporter: Keith Chow Priority: Minor Attachments: ServerConfiguration.java.diff The following is the default 0.5 java broker config.xml structure for protection I/O related configuration. broker connector qpidniofalse/qpidnio protectio enabledfalse/enabled /protectio /connector /broker But ServerConfiguration expects a config value with key broker.connector.protectio.enabled, which makes the broker. prefix appears to be extraneous if the default config's XML structure is correct. -- 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-1999) the Clear button in each VirtualHost Notifications area still clears all server-wide Notifications
the Clear button in each VirtualHost Notifications area still clears all server-wide Notifications -- Key: QPID-1999 URL: https://issues.apache.org/jira/browse/QPID-1999 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 VirtualHost Notifications areas usedto display all Notifications for the entire server, but have now been restricted to those only for the specific VirtualHost in question. However, the clear button in each VirtualHost Notifications area still clears all server-wide Notifications as before. -- 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-1999) the Clear button in each VirtualHost Notifications area still clears all server-wide Notifications
[ https://issues.apache.org/jira/browse/QPID-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1999: - Status: Ready To Review (was: In Progress) the Clear button in each VirtualHost Notifications area still clears all server-wide Notifications -- Key: QPID-1999 URL: https://issues.apache.org/jira/browse/QPID-1999 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 VirtualHost Notifications areas usedto display all Notifications for the entire server, but have now been restricted to those only for the specific VirtualHost in question. However, the clear button in each VirtualHost Notifications area still clears all server-wide Notifications as before. -- 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] Assigned: (QPID-1999) the Clear button in each VirtualHost Notifications area still clears all server-wide Notifications
[ https://issues.apache.org/jira/browse/QPID-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-1999: Assignee: Aidan Skinner (was: Robbie Gemmell) Hi Aidan, can you review this change please, thanks. the Clear button in each VirtualHost Notifications area still clears all server-wide Notifications -- Key: QPID-1999 URL: https://issues.apache.org/jira/browse/QPID-1999 Project: Qpid Issue Type: Bug Components: Java Management : JMX Console Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Aidan Skinner Fix For: 0.6 The VirtualHost Notifications areas usedto display all Notifications for the entire server, but have now been restricted to those only for the specific VirtualHost in question. However, the clear button in each VirtualHost Notifications area still clears all server-wide Notifications as before. -- 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: Incorrects timestamps for QMF messages with a broker running on Windows
Hi Julien, I was wondering if it could be possible to have QPID-1904 resolved for 0.6. (Unless it has already been addressed, in that case please forgive me) https://issues.apache.org/jira/browse/QPID-1904 Basically, when running a broker on windows, all the time stamps for the QMF messages are wrong by a few years (give or take ;-)) E-gads... That's bad. When running the broker on linux, everything is fine. I guess the fix is trivial when you know where to look, could someone have a look at it please? Yes, I'll have a look at it. Can you give me a simple way to reproduce the problem, if it's not already in the jira? Thanks, -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Incorrects timestamps for QMF messages with a broker running on Windows
I think the easiest way is the one described in the JIRA. Well, ok, it's not very obvious in the JIRA, I'll try again :-). - Edit this file : qpid\python\qpid\disp.py. Line 178 (in timestamp()), Add this : print gmtime (nsec / 10) - Start a broker on windows - Start qpid-tool and connect to the broker - type show id of a queue - Above the queue information you should have something like that https://issues.apache.org/jira/secure/attachment/12410666/qpid-dates.png (red rectangle). In this sample the queue was allegedly create in november 1994 :-) Let me know if I can help, Julien -Message d'origine- De : Steve Huston [mailto:shus...@riverace.com] Envoyé : mercredi 22 juillet 2009 14:01 À : dev@qpid.apache.org Objet : RE: Incorrects timestamps for QMF messages with a broker running on Windows Hi Julien, I was wondering if it could be possible to have QPID-1904 resolved for 0.6. (Unless it has already been addressed, in that case please forgive me) https://issues.apache.org/jira/browse/QPID-1904 Basically, when running a broker on windows, all the time stamps for the QMF messages are wrong by a few years (give or take ;-)) E-gads... That's bad. When running the broker on linux, everything is fine. I guess the fix is trivial when you know where to look, could someone have a look at it please? Yes, I'll have a look at it. Can you give me a simple way to reproduce the problem, if it's not already in the jira? Thanks, -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org P Please consider your environmental responsibility before printing this email * Ce message peut contenir des informations confidentielles. Les idees et opinions presentees dans ce message sont celles de son auteur, et ne representent pas necessairement celles du groupe ABC arbitrage. Au cas ou il ne vous serait pas destine, merci d'en aviser l'expediteur immediatement et de le supprimer. This message may contain confidential information. Any views or opinions presented are solely those of its author and do not necessarily represent those of ABC arbitrage. If you are not the intended recipient, please notify the sender immediately and delete it. * - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1967) gather list of available exchange types from broker instead of hardcoding in console
[ https://issues.apache.org/jira/browse/QPID-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-1967: Assignee: Aidan Skinner (was: Robbie Gemmell) Hi Aidan, can you review this change please, thanks. gather list of available exchange types from broker instead of hardcoding in console Key: QPID-1967 URL: https://issues.apache.org/jira/browse/QPID-1967 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Aidan Skinner -- 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-1967) gather list of available exchange types from broker instead of hardcoding in console
[ https://issues.apache.org/jira/browse/QPID-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1967: - Status: Ready To Review (was: In Progress) gather list of available exchange types from broker instead of hardcoding in console Key: QPID-1967 URL: https://issues.apache.org/jira/browse/QPID-1967 Project: Qpid Issue Type: Sub-task Components: Java Management : JMX Console Reporter: Robbie Gemmell Assignee: Robbie Gemmell -- 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-1961) widen viewMessages(int From, int To) AMQQueueMBean method to use Long values
[ https://issues.apache.org/jira/browse/QPID-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1961: - Fix Version/s: 0.6 Summary: widen viewMessages(int From, int To) AMQQueueMBean method to use Long values (was: widen viewMessages(int From, int To) and getMessageCount() AMQQueueMBean methods to use Long values) changing getMessageCount() from an Integer return type to Long will break compatibility with the JMX CLI. As filling a queue with 2^31 messages involves an extreme amount of memory it is not a typical scenario at present and so changing this will be postponed until future alterations to the management API necessitate a general break in compatibility. widen viewMessages(int From, int To) AMQQueueMBean method to use Long values Key: QPID-1961 URL: https://issues.apache.org/jira/browse/QPID-1961 Project: Qpid Issue Type: Sub-task Components: Java Broker, Java Management : JMX Console Affects Versions: M2.1, M3, M4, 0.5 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Minor Fix For: 0.6 The viewMessages() operation is inherently limited to viewing the first 2^31 undelivered messages on the queue at any given time due to its use of int parameters. Equally, getMessageCount() returns an int value. However, the SimpleAMQQueue implementation is not limited to 2^31 messages and so there is potential that not all messages can be viewed. This should be rectified by increasing the parameter range to Long. The viewMessages() implementation will then be limited to viewing ANY 2^31 messages on the queue as the TabularData OpenData result sets used to support generic JMX clients are also fixed in size by an int index. -- 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] Assigned: (QPID-1961) widen viewMessages(int From, int To) AMQQueueMBean method to use Long values
[ https://issues.apache.org/jira/browse/QPID-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-1961: Assignee: Aidan Skinner (was: Robbie Gemmell) Hi Aidan, can you review this change please, thanks. widen viewMessages(int From, int To) AMQQueueMBean method to use Long values Key: QPID-1961 URL: https://issues.apache.org/jira/browse/QPID-1961 Project: Qpid Issue Type: Sub-task Components: Java Broker, Java Management : JMX Console Affects Versions: M2.1, M3, M4, 0.5 Reporter: Robbie Gemmell Assignee: Aidan Skinner Priority: Minor Fix For: 0.6 The viewMessages() operation is inherently limited to viewing the first 2^31 undelivered messages on the queue at any given time due to its use of int parameters. Equally, getMessageCount() returns an int value. However, the SimpleAMQQueue implementation is not limited to 2^31 messages and so there is potential that not all messages can be viewed. This should be rectified by increasing the parameter range to Long. The viewMessages() implementation will then be limited to viewing ANY 2^31 messages on the queue as the TabularData OpenData result sets used to support generic JMX clients are also fixed in size by an int index. -- 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-1918) Patches/files for Windows QMF plug-in support
[ https://issues.apache.org/jira/browse/QPID-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734116#action_12734116 ] Pete MacKinnon commented on QPID-1918: -- Hi Steve, I will provide a future patch that will alllow for PipeHandle to have a local _pipe as well as the select-friendly Socket approach. I will revisit the ManagementAgentImpl.cpp code based on your suggestion but there seems to be non-deterministic behavior between the connection and publish logic which can sleep the publish thread for an inadvertently long time. The uuid changes are actually more a less a revert to a previous version in Qpid. It was the only way I could surmount some significant code-level integration issues. I guess I could revisit this by trying to mitigate on the Condor side but am not optimistic. The HAVE_ flags for pid_t and ssize_t are artificial and would not currently fall out of the Condor autotools step. They are specifically there for code-level integration between Qpid and Condor. I raised https://issues.apache.org/jira/browse/QPID-1951 to suggest we bury those Posix decls in the portability layer to avoid this hack. I have been working on the Cmake changes I need and I think it looks pretty good. Once I have fixed some of the qmf-agent example QMF generation steps, I'll submit. In summary, I will attach an updated patch zip (hopefully soon). \Pete Patches/files for Windows QMF plug-in support - Key: QPID-1918 URL: https://issues.apache.org/jira/browse/QPID-1918 Project: Qpid Issue Type: New Feature Components: Qpid Managment Framework Environment: Windows XP SP3, VC++ 9.0 Reporter: Pete MacKinnon Assignee: Steve Huston Attachments: qpid-1918.zip Various files for the Windows QMF plug-in support in cpp, based off revision: 785848 Need Static builds (release and debug) for correct runtime integration with Condor: src/broker.vcproj src/client.vcproj src/common.vcproj src/qmfagent.vcproj src/qmfconsole.vcproj src/qpid.sln src/qpidbroker.vcproj - Changed to provide compile flags required for header file integration of Posix types declared by both Qpid and Condor: src/qpid/sys/windows/IntegerTypes.h src/qpid/sys/windows/uuid.cpp src/qpid/sys/windows/uuid.h - Modified signature of PipeHandle ctor and fixed a Windows race condition in the processing loop: src/qpid/agent/ManagementAgentImpl.cpp - Refactored the pipe code so that Condor can get a true socket fd it can select on in daemon_core: src/qpid/sys/Pipehandle.h src/qpid/sys/posix/PipeHandle.cpp src/qpid/sys/windows/PipeHandle.cpp - Removed explicit dependency on Debug libs since we now have even more targets. Added Apache license: examples/qmf_agent.vcproj - Added Apache license: src/protocol_gen.mak examples/qmf-agent/example_gen.mak - Updated QMF Agent example README: examples/README -- 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-2000) retrieving attributes for the queue selection list takes excessively long with large numbers of queues
retrieving attributes for the queue selection list takes excessively long with large numbers of queues -- Key: QPID-2000 URL: https://issues.apache.org/jira/browse/QPID-2000 Project: Qpid Issue Type: Improvement Components: Java Management : JMX Console Affects Versions: M4, M3, M2.1, M2, 0.5 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.6 Retrieving attributes for the queue selection list takes excessively long with a large (eg 10k) number of queues, freezing the interface for several seconds. This is due to the sheer number of RPC calls that have to be made to retrieve the data, so a method will be added to the JMX mbeans to allow collection of the information in a single call, and the console adapted accordingly. -- 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-1904) Timestamps are incorrect
[ https://issues.apache.org/jira/browse/QPID-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734139#action_12734139 ] Andrew Stitcher commented on QPID-1904: --- I suspect this is an issue with the qmf code using the underlying qpid::sys:AbsTime class representation directly and assuming it is a since the 1970 epoch. This is not not the case - as documented in cpp/src/qpid/sys/Time.h the value is nanosecs since an unknown base. Accidentally it is probably since 1/1/970 on unix systems, but on Windows I'd bet the epoch is different. This class was never intended to represent calendar time and so there is no facility to convert it directly. I guess the quick fix is to shift the epoch base of the windows code when converting AbsTime to Duration since that is the only way to gain access to the internal nanosec from epoch value. A better way would be to introduce a calendar date to AbsTime constructor so that you can specify the epoch base when you convert to Duration (negative values of AbsTime are perfectly meaningful for this class). Timestamps are incorrect Key: QPID-1904 URL: https://issues.apache.org/jira/browse/QPID-1904 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Affects Versions: 0.5 Environment: Windows XP Reproduced both with the python API and the .Net API Reporter: Julien Lavigne du Cadet Attachments: qpid-dates.png The timestamps for configuration and instrumentation messages are incorrect both with the python and the .Net api. According to the documentation All timestamps are uint64 values representing nanoseconds since the epoch (January 1, 1970). However, the dates resulting can be several years in the past or in the future. To reproduce with the python api : - in disp.py, line 178 add the following line : print gmtime (nsec / 10) - start qpid-tool and list the queues = the full dates will be displayed -- 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: Incorrects timestamps for QMF messages with a broker running on Windows
On Wed, 2009-07-22 at 08:00 -0400, Steve Huston wrote: Basically, when running a broker on windows, all the time stamps for the QMF messages are wrong by a few years (give or take ;-)) E-gads... That's bad. When running the broker on linux, everything is fine. I guess the fix is trivial when you know where to look, could someone have a look at it please? Yes, I'll have a look at it. Can you give me a simple way to reproduce the problem, if it's not already in the jira? As I noted in the jira (just now) it almost certainly because the epochs for the Windows and Unix representations in qpid::sys::AbsTime are different, and the qmf code erroneously assumes the unix epoch. Fixing this is another thing though! Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1904) Timestamps are incorrect
[
https://issues.apache.org/jira/browse/QPID-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734145#action_12734145
]
Andrew Stitcher commented on QPID-1904:
---
From inspection I suspect this code in cpp/src/qpid/sys/windows/Time.cpp:
Duration::Duration(const AbsTime time0) : nanosecs(0) {
time_period p(ptime(min_date_time), time0.timepoint);
nanosecs = p.length().total_nanoseconds();
}
I suspect that ptime(min_date_time) is NOT the 1970 epoch.
Timestamps are incorrect
Key: QPID-1904
URL: https://issues.apache.org/jira/browse/QPID-1904
Project: Qpid
Issue Type: Bug
Components: Qpid Managment Framework
Affects Versions: 0.5
Environment: Windows XP
Reproduced both with the python API and the .Net API
Reporter: Julien Lavigne du Cadet
Attachments: qpid-dates.png
The timestamps for configuration and instrumentation messages are incorrect
both with the python and the .Net api.
According to the documentation All timestamps are uint64 values representing
nanoseconds since the epoch (January 1, 1970). However, the dates resulting
can be several years in the past or in the future.
To reproduce with the python api :
- in disp.py, line 178 add the following line :
print gmtime (nsec / 10)
- start qpid-tool and list the queues = the full dates will be displayed
--
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] fanout exchange, JMX bindings() results
On Wed, Jul 22, 2009 at 10:19 AM, Robbie Gemmellrobbie.gemm...@gmail.com wrote: I dont really like that, it isnt representative of whats actually going on, so id like to change it to return a single CompositeData element within the TabularData which contains a 'wildcard binding' with all the queue names in the associated list. This would lead to a results view which looked like below: http://people.apache.org/~robbie/qpid/gsoc/screenshots_22july2009/fanout_exchange2.png I think thats more in keeping with whats actually going on and more descriptive of how the exchange actually works. That looks like a good plan to me. :) - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2002) [Logging] Migrate existing logging to new framework
[Logging] Migrate existing logging to new framework --- Key: QPID-2002 URL: https://issues.apache.org/jira/browse/QPID-2002 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie As described in the Technical specifcation there are some existing messages that overlap with the new logging framework messages: http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification These old messages need migrated and any new messages need added and then tested according to the test specfication: http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Test+Specification -- 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-1980) Java broker does not parse protection I/O configuration with expected XML structure
[ https://issues.apache.org/jira/browse/QPID-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1980: - Status: Ready To Review (was: In Progress) Java broker does not parse protection I/O configuration with expected XML structure --- Key: QPID-1980 URL: https://issues.apache.org/jira/browse/QPID-1980 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.5 Reporter: Keith Chow Assignee: Martin Ritchie Priority: Minor Attachments: ServerConfiguration.java.diff The following is the default 0.5 java broker config.xml structure for protection I/O related configuration. broker connector qpidniofalse/qpidnio protectio enabledfalse/enabled /protectio /connector /broker But ServerConfiguration expects a config value with key broker.connector.protectio.enabled, which makes the broker. prefix appears to be extraneous if the default config's XML structure is correct. -- 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-1992) [Logging] Create Operational logging framework
[ https://issues.apache.org/jira/browse/QPID-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1992: - Status: Ready To Review (was: In Progress) [Logging] Create Operational logging framework -- Key: QPID-1992 URL: https://issues.apache.org/jira/browse/QPID-1992 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Summary: As a first step in improving the Java broker's logging operation this work will provide a new abstraction layer for logging. Full Design and Technical Details can be found on confluence: http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification -- 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] Assigned: (QPID-1992) [Logging] Create Operational logging framework
[ https://issues.apache.org/jira/browse/QPID-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-1992: Assignee: Aidan Skinner (was: Martin Ritchie) Hi Aidan, can you review this change please [Logging] Create Operational logging framework -- Key: QPID-1992 URL: https://issues.apache.org/jira/browse/QPID-1992 Project: Qpid Issue Type: New Feature Components: Java Broker Reporter: Martin Ritchie Assignee: Aidan Skinner Summary: As a first step in improving the Java broker's logging operation this work will provide a new abstraction layer for logging. Full Design and Technical Details can be found on confluence: http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification -- 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] Assigned: (QPID-1980) Java broker does not parse protection I/O configuration with expected XML structure
[ https://issues.apache.org/jira/browse/QPID-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-1980: Assignee: Aidan Skinner (was: Martin Ritchie) Hi Aidan, Can you review this change please Java broker does not parse protection I/O configuration with expected XML structure --- Key: QPID-1980 URL: https://issues.apache.org/jira/browse/QPID-1980 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.5 Reporter: Keith Chow Assignee: Aidan Skinner Priority: Minor Attachments: ServerConfiguration.java.diff The following is the default 0.5 java broker config.xml structure for protection I/O related configuration. broker connector qpidniofalse/qpidnio protectio enabledfalse/enabled /protectio /connector /broker But ServerConfiguration expects a config value with key broker.connector.protectio.enabled, which makes the broker. prefix appears to be extraneous if the default config's XML structure is correct. -- 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: [GSoC] Queue MBean viewMessages + viewMessageContent operations
2009/7/21 Robbie Gemmell robbie.gemm...@gmail.com: Thoughts? I think dealing with queues having more than 2 billion messages on them can safely be deferred since it is mostly of theoretical interest. Most support teams are going to want to alert on queue depth long before that size is reached. RG - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
