[jira] Created: (QPID-2842) references to other objects in qpid-tool use id that doesn't match anything else

2010-09-02 Thread Gordon Sim (JIRA)
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

2010-09-02 Thread Sorin S.
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

2010-09-02 Thread Ted Ross (JIRA)

 [ 
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

2010-09-02 Thread Robbie Gemmell (JIRA)
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

2010-09-02 Thread Rajith Attapattu (JIRA)
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

2010-09-02 Thread Rajith Attapattu (JIRA)
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.

2010-09-02 Thread Ken Giusti (JIRA)
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.

2010-09-02 Thread Ken Giusti (JIRA)

 [ 
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