qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6831) Remove logging from constructor of ConnectionScopedRuntimeException
Date Fri, 06 Nov 2015 23:34:10 GMT

    [ https://issues.apache.org/jira/browse/QPID-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14994702#comment-14994702
] 

Keith Wall commented on QPID-6831:
----------------------------------

We have CSRE used in the following situations:

# Used in the protocol layers to represent abnormal situations arising from unexpected input,
for instance frame decoding errors, message conversion errors
# Used in protocol layers when virtualhost state changes occur during message enqueue
# In the AMQP 1.0 layers used for security exceptions, queue name/UUID collisions
# Used in a few places where logically control should never e.g. IOExceptions from in-memory
operations, default: clauses on switch clauses.
# Used in model operations
## In queue/exchange/binding creation in situations like UUID collision, JMS selector parsing
error
## In HA used to represent failures to perform node operations (transfer master etc) owning
to the failure to contact quorum nodes
# In HA, used to cause client disconnection when the group elects a new master

We are currently logging CSRE on the following paths of control:

# IO threads - NonBlockingConnection logs CSRE (or IOException) at INFO with exception message
only.
# HTTP threads - AbstractServlet logs CSRE at ERROR complete with whole stack
# JMX threads - MbeanInvocationHandler logs CSRE at ERROR complete with whole stack
# Housekeeping threads CSRE would be fatal to the Broker if they were to bubble to the top
level. An exception is QueueRunner task, that catches and logs CSREs. 

It is clear there are a number of places were CSREs are being misused and in the long term
these should be address.  However at this point in the cycle I think a refactoring would be
inappropriate. Instead I think   AbstractServlet/MbeanInvocationHandler should be changed
to log CSRE at INFO  (rather like NBC) to avoid polluting the logs with ERRORs that don't
truly represent ERRORs.





> Remove logging from constructor of ConnectionScopedRuntimeException
> -------------------------------------------------------------------
>
>                 Key: QPID-6831
>                 URL: https://issues.apache.org/jira/browse/QPID-6831
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Keith Wall
>            Assignee: Keith Wall
>            Priority: Minor
>             Fix For: qpid-java-6.0
>
>
> {{ConnectionScopedRuntimeException}} currently logs itself at ERROR, with a complete
stacktrace, on construction.  The CSRE is intended to be used when the Broker detects an abnormal
situation which should  cause only the affected connection to be closed, for instance, a badly
composed frame.
> The responsibility for logging the CSRE need to be taken higher up the stack, so it can
chose the appropriate level of detail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message