[jira] Created: (QPID-2842) references to other objects in qpid-tool use id that doesn't match anything else
references to other objects in qpid-tool use id that doesn't match anything else Key: QPID-2842 URL: https://issues.apache.org/jira/browse/QPID-2842 Project: Qpid Issue Type: Bug Components: C++ Broker, python tools, Qpid Managment Framework Affects Versions: 0.7 Reporter: Gordon Sim Priority: Critical E.g. in the following qpid-tool session it is impossible to accurately identify the session for a given subscription: qpid: list subscription Object Summary: ID Created Destroyed Index = 128 08:07:24 - 0-1447-1-0-13:0-1447-1-0-25:v2TopicHB 129 08:07:24 - 0-1447-1-0-13:0-1447-1-0-23:v2TopicUI 130 08:07:24 - 0-1447-1-0-13:0-1447-1-0-14:rdest 131 08:07:24 - 0-1447-1-0-13:0-1447-1-0-18:tdest 138 08:07:37 - 0-1447-1-0-35:0-1447-1-0-36:my-queue 127 08:07:24 - 0-1447-1-0-13:0-1447-1-0-21:v2dest qpid: show 138 Object of type: org.apache.qpid.broker:subscription:_data(7cc0ee44-57d4-2ed7-1a4b-3156ed9a4343) Attribute 138 = sessionRef0-1447-1-0-35 queueRef 0-1447-1-0-36 name u'my-queue' browsing False acknowledged True exclusive False creditModeu'CREDIT' arguments {} delivered 0 The session ref is shown as 0-1447-1-0-35, but this doesn't help me identify the session... qpid: list session Object Summary: ID Created Destroyed Index == 137 08:07:37 - 0-0-1-0-3:7c777430-1622-4ad2-923e-40e7074f1df4 126 08:07:24 - 0-0-1-0-3:GRST500.4398.1 qpid: show 137 Object of type: org.apache.qpid.broker:session:_data(9a57d0d2-8b17-8c84-4fac-5c9a96c2cf75) Attribute 137 vhostRef 0-0-1-0-3 name u'7c777430-1622-4ad2-923e-40e7074f1df4' channelId 1 connectionRef 0-1447-1-0-34 detachedLifespan 0 attached True expireTime None maxClientRate None framesOutstanding 0 TxnStarts 0 TxnCommits 0 TxnRejects 0 TxnCount 0 clientCredit 0 qpid: show 126 Object of type: org.apache.qpid.broker:session:_data(9a57d0d2-8b17-8c84-4fac-5c9a96c2cf75) Attribute 126 == vhostRef 0-0-1-0-3 name u'GRST500.4398.1' channelId 1 connectionRef 0-1447-1-0-12 detachedLifespan 0 attached True expireTime None maxClientRate None framesOutstanding 0 TxnStarts 0 TxnCommits 0 TxnRejects 0 TxnCount 0 clientCredit 0 qpid: ...as neither the list nor the detail view for sessions use the id of that form. -- 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] Updated: (QPID-2835) Implement connections (CON) operational logging on 0-10
Hi Martin, Thanks very much for your feedback. The main problem I had with the current framework is the fact that the LogSubject objects seem to have knowledge about broker hierarchy (eg the SubscriptionLogSubject instantiates a QueueLogSubject, also the ConnectionLogSubject takes a AMQProtocolSession which is pre 0-10, etc) - this makes those LogSubject(s) hard to re-use and things can get even harder if 1-0 comes with a different Model Object hierarchy. Given the LogSubject role is to provide a subject (ultimately a label) to the business message pertaining to a broker specific Object state I thought that the object itself is in the best position to have all the information needed to generate the log subject and therefore the logging framework can consist of a GenericLogActor which would take something like: (LogSubject) Object and format it using the selected method from a class generated from o.a.q.server.logging.messages.*_logmessages.properties (where the formatting takes place). So our Model Object encapsulates all the info needed to log itself up. This allows decoupling of the logging framework from the need to know anything about the objects it logs, it only needs to call the toLogString method defined in the LogSubject interface. It could also log anything implementing a LogSubject interface via the same GenericActor. Otherwise we might need to create new Actors and LogSubject's to fit any new Model Object which doesn't seem right to me. As of now, with the proposed patches, the 0-10 operational logging works independent of the pre 0-10 one and I think it is simpler and more flexible. This is why Qpid-2835 seems inconsistent with the 0-8/0-9, as it is designed to sit alongside the current framework. If agreed and within the planned October release scope, we can refactor the current implementation also, effectively reducing the logging framework to a LogSubject interface, a GenericActor and o.a.q.server.logging.messages.* classes, still obeying the schema you highlighted: LogActors - Logging Framework LogActors - Model Objects but we might as well leave it as it is. The move to slf4j is something very good to have, but it requires major changes as you know. Once we have it, we can hook it at the o.a.q.server.logging.rawloggers level. But to achieve that, we need to give up the log4j.xml file watching, the org.apache.log4j packages (eg the QpidCompositeRollingAppender), we have jmx console issues to take care of, couple of hardcoded places to look at and about 94 straight changes, not to mention the testing framework as well. All in all, not a trivial move but doable nevertheless. I would be very interested to hear thoughts on the above from anyone on the list. Thank you, Sorin On Wed, Sep 1, 2010 at 7:12 PM, Martin Ritchie ritch...@apache.org wrote: Hi Sorin, I've been watching your changes wrt the Operational Logging apologies for not replying to your thread over the weekend but I wasn't at a computer. I think the addition of the toLogString() is the wrong approach here. The responsibility for the logging format should not lie with the individual model objects. From our discussion on QPID-2780 this doesn't seem like the same approach you are now taking, what changed? The change suggested by the patch on QPID-2835 will introduce inconsistency in the operation logging. Something that its introduction was designed to reduce. The LogActors are that point where the consistency is gained. By locating the LogFormat and the string builder in one location the LogActor has full responsibility of formatting log messages. The approach that I would have taken here is to expose the required common methods for logging on our Session and Connection models. This would then mean that we would have two clean interfaces boundaries: LogActors - Logging Framework LogActors - Model Objects This would mean that the desire to move to slf4j would be a matter of adjusting the Logging Framework and the adding consistent 1-0 logging would be simply a matter of implementing the model interfaces. The only code that I would expect to see added to the 0-10 Connection code paths is the introduction of Logging commands. The 0-10 Model Objects should have nothing to do with formatting logging statements. Cheers Martin On 31 August 2010 12:18, Sorin Suciu (JIRA) qpid-...@incubator.apache.org wrote: [ https://issues.apache.org/jira/browse/QPID-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sorin Suciu updated QPID-2835: -- Attachment: qpid-2835.patch Implement connections (CON) operational logging on 0-10 --- Key: QPID-2835 URL: https://issues.apache.org/jira/browse/QPID-2835 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu
[jira] Assigned: (QPID-2842) references to other objects in qpid-tool use id that doesn't match anything else
[ https://issues.apache.org/jira/browse/QPID-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2842: -- Assignee: Ted Ross references to other objects in qpid-tool use id that doesn't match anything else Key: QPID-2842 URL: https://issues.apache.org/jira/browse/QPID-2842 Project: Qpid Issue Type: Bug Components: C++ Broker, python tools, Qpid Managment Framework Affects Versions: 0.7 Reporter: Gordon Sim Assignee: Ted Ross Priority: Critical E.g. in the following qpid-tool session it is impossible to accurately identify the session for a given subscription: qpid: list subscription Object Summary: ID Created Destroyed Index = 128 08:07:24 - 0-1447-1-0-13:0-1447-1-0-25:v2TopicHB 129 08:07:24 - 0-1447-1-0-13:0-1447-1-0-23:v2TopicUI 130 08:07:24 - 0-1447-1-0-13:0-1447-1-0-14:rdest 131 08:07:24 - 0-1447-1-0-13:0-1447-1-0-18:tdest 138 08:07:37 - 0-1447-1-0-35:0-1447-1-0-36:my-queue 127 08:07:24 - 0-1447-1-0-13:0-1447-1-0-21:v2dest qpid: show 138 Object of type: org.apache.qpid.broker:subscription:_data(7cc0ee44-57d4-2ed7-1a4b-3156ed9a4343) Attribute 138 = sessionRef0-1447-1-0-35 queueRef 0-1447-1-0-36 name u'my-queue' browsing False acknowledged True exclusive False creditModeu'CREDIT' arguments {} delivered 0 The session ref is shown as 0-1447-1-0-35, but this doesn't help me identify the session... qpid: list session Object Summary: ID Created Destroyed Index == 137 08:07:37 - 0-0-1-0-3:7c777430-1622-4ad2-923e-40e7074f1df4 126 08:07:24 - 0-0-1-0-3:GRST500.4398.1 qpid: show 137 Object of type: org.apache.qpid.broker:session:_data(9a57d0d2-8b17-8c84-4fac-5c9a96c2cf75) Attribute 137 vhostRef 0-0-1-0-3 name u'7c777430-1622-4ad2-923e-40e7074f1df4' channelId 1 connectionRef 0-1447-1-0-34 detachedLifespan 0 attached True expireTime None maxClientRate None framesOutstanding 0 TxnStarts 0 TxnCommits 0 TxnRejects 0 TxnCount 0 clientCredit 0 qpid: show 126 Object of type: org.apache.qpid.broker:session:_data(9a57d0d2-8b17-8c84-4fac-5c9a96c2cf75) Attribute 126 == vhostRef 0-0-1-0-3 name u'GRST500.4398.1' channelId 1 connectionRef 0-1447-1-0-12 detachedLifespan 0 attached True expireTime None maxClientRate None framesOutstanding 0 TxnStarts 0 TxnCommits 0 TxnRejects 0 TxnCount 0 clientCredit 0 qpid: ...as neither the list nor the detail view for sessions use the id of that form. -- 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-2843) remove redundant/duplicated logging
remove redundant/duplicated logging --- Key: QPID-2843 URL: https://issues.apache.org/jira/browse/QPID-2843 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Minor Fix For: 0.7, 0.6 Following introduction of the operational logging framework there has been some overlap between the existing logging and the added logging, which should be removed. A good example is the startup information, which is logged in different formats on stdout and in the log file, with some messsages only going to one and some going to both. -- 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-2844) JMS client should use the exchange given in the address if the exchange name is not explicitly given in x-bindings
JMS client should use the exchange given in the address if the exchange name is not explicitly given in x-bindings --- Key: QPID-2844 URL: https://issues.apache.org/jira/browse/QPID-2844 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.7 Consider the following address MRKT;{link:{x-declare:{arguments:{'qpid.last_value_queue':1}},x-bindings:[{key:'NYSE.#'},{key:'NASDAQ.#'},{key:'CNTL.#'}]}} In the x-bindings section, the exchange names are not specified. In that case the JMS client should use MRKT as the exchange name. If the address doesn't resolve to an exchange (that is it resolves to a queue) then amq.topic is used as the default 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] Created: (QPID-2845) JMS client should allow arbitary arguments map in the x-bindings section
JMS client should allow arbitary arguments map in the x-bindings section Key: QPID-2845 URL: https://issues.apache.org/jira/browse/QPID-2845 Project: Qpid Issue Type: Bug Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.7 Currently the JMS client does not allow an arbitrary arguments map in the x-bindings section. Instead options like qpid.max_size are specified as top level elements within x-bindings and are also verified. Therefore the code needs to be changed anytime a new option is added. -- 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-2846) QMF: python console crashes on race condition when deleting an agent.
QMF: python console crashes on race condition when deleting an agent. - Key: QPID-2846 URL: https://issues.apache.org/jira/browse/QPID-2846 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: all Reporter: Ken Giusti Assignee: Ken Giusti If an agent is deleted while reply messages from that agent are still pending on the queue, the python console can crash due to a stale sequence id: Exception in thread Thread for broker: grm31.lab:5672: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 522, in __bootstrap_inner self.run() File /home/ernie/lib/python/qmf/console.py, line 2813, in run self._v2Dispatch(item.data) File /home/ernie/lib/python/qmf/console.py, line 2695, in _v2Dispatch agent._handleQmfV2Message(opcode, mp, ah, content) File /home/ernie/lib/python/qmf/console.py, line 3418, in _handleQmfV2Message elif opcode == '_exception': self._v2HandleException(mp, ah, content) File /home/ernie/lib/python/qmf/console.py, line 3282, in _v2HandleException pair.cancel(text) File /home/ernie/lib/python/qmf/console.py, line 3507, in cancel self._complete() File /home/ernie/lib/python/qmf/console.py, line 3545, in _complete self.agent._clearContext(self.sequence) File /home/ernie/lib/python/qmf/console.py, line 3061, in _clearContext x = self.contextMap.pop(sequence) KeyError: 'pop(): dictionary is empty' -- 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] Closed: (QPID-2846) QMF: python console crashes on race condition when deleting an agent.
[ https://issues.apache.org/jira/browse/QPID-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti closed QPID-2846. Resolution: Fixed QMF: python console crashes on race condition when deleting an agent. - Key: QPID-2846 URL: https://issues.apache.org/jira/browse/QPID-2846 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: all Reporter: Ken Giusti Assignee: Ken Giusti If an agent is deleted while reply messages from that agent are still pending on the queue, the python console can crash due to a stale sequence id: Exception in thread Thread for broker: grm31.lab:5672: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 522, in __bootstrap_inner self.run() File /home/ernie/lib/python/qmf/console.py, line 2813, in run self._v2Dispatch(item.data) File /home/ernie/lib/python/qmf/console.py, line 2695, in _v2Dispatch agent._handleQmfV2Message(opcode, mp, ah, content) File /home/ernie/lib/python/qmf/console.py, line 3418, in _handleQmfV2Message elif opcode == '_exception': self._v2HandleException(mp, ah, content) File /home/ernie/lib/python/qmf/console.py, line 3282, in _v2HandleException pair.cancel(text) File /home/ernie/lib/python/qmf/console.py, line 3507, in cancel self._complete() File /home/ernie/lib/python/qmf/console.py, line 3545, in _complete self.agent._clearContext(self.sequence) File /home/ernie/lib/python/qmf/console.py, line 3061, in _clearContext x = self.contextMap.pop(sequence) KeyError: 'pop(): dictionary is empty' -- 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