[ 
https://issues.apache.org/jira/browse/QPID-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomas Vavricka updated QPID-8694:
---------------------------------
    Description: 
When an exception happens in logger itself, it is handled by 
BrokerLoggerStatusListener, leading in some cases to repeated messages, e.g.:
{noformat}
2025-04-02T10:35:42,245Z ERROR [AsyncAppender-Worker-graylog] 
(o.a.q.s.l.l.BrokerLoggerStatusListener) - Unexpected error whilst trying to 
store log entry. Log messages could be lost.
java.net.ConnectException: Connection refused
        at java.base/sun.nio.ch.Net.pollConnect(Native Method)
        at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:672)
        at 
java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:554)
        at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:602)
        at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
        at java.base/java.net.Socket.connect(Socket.java:633)
        at de.siegmar.logbackgelf.TcpConnection.connect(TcpConnection.java:73)
        at de.siegmar.logbackgelf.TcpConnection.write(TcpConnection.java:56)
        at 
de.siegmar.logbackgelf.GelfTcpAppender.lambda$sendMessage$1(GelfTcpAppender.java:194)
        at 
de.siegmar.logbackgelf.pool.SimpleObjectPool.execute(SimpleObjectPool.java:66)
        at 
de.siegmar.logbackgelf.GelfTcpAppender.sendMessage(GelfTcpAppender.java:194)
        at 
de.siegmar.logbackgelf.GelfTcpAppender.appendMessage(GelfTcpAppender.java:168)
        at 
de.siegmar.logbackgelf.AbstractGelfAppender.append(AbstractGelfAppender.java:101)
        at 
de.siegmar.logbackgelf.AbstractGelfAppender.append(AbstractGelfAppender.java:27)
        at 
ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85)
        at 
ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
        at 
ch.qos.logback.core.AsyncAppenderBase$Worker.run(AsyncAppenderBase.java:302)

{noformat}
 

Described behavior occurs due to the logging of logger errors (e.g. when 
graylog server is unavailable). It can be switched off by creating a 
BrokerLogInclusionRule, e.g. via curl command:
{code:java}
curl -d 
'{"name":"graylog","type":"NameAndLevel","durable":true,"loggerName":"org.apache.qpid.server.logging.logback.BrokerLoggerStatusListener","level":"OFF"}'
 
http://<username>:<password>@<hostname>:<port>/api/latest/brokerloginclusionrule/logfile
  {code}
This command sets log level OFF (disables all log messages) produced by the 
class org.apache.qpid.server.logging.logback.BrokerLoggerStatusListener.

As the repeated error messages significantly increase the log size, the 
behavior of the BrokerLoggerStatusListener should be changed to log by default 
only the error message without the stacktrace. When log level DEBUG or TRACE is 
enabled, the full stacktrace should be logged for the error analysis purpose.

  was:
When an exception happens in logger itself, it is handled by 
BrokerLoggerStatusListener, leading in some cases to repeated messages, e.g.:
{noformat}
2025-04-02T10:35:42,245Z ERROR [AsyncAppender-Worker-graylog] 
(o.a.q.s.l.l.BrokerLoggerStatusListener) - Unexpected error whilst trying to 
store log entry. Log messages could be lost.
java.net.ConnectException: Connection refused
        at java.base/sun.nio.ch.Net.pollConnect(Native Method)
        at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:672)
        at 
java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:554)
        at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:602)
        at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
        at java.base/java.net.Socket.connect(Socket.java:633)
        at de.siegmar.logbackgelf.TcpConnection.connect(TcpConnection.java:73)
        at de.siegmar.logbackgelf.TcpConnection.write(TcpConnection.java:56)
        at 
de.siegmar.logbackgelf.GelfTcpAppender.lambda$sendMessage$1(GelfTcpAppender.java:194)
        at 
de.siegmar.logbackgelf.pool.SimpleObjectPool.execute(SimpleObjectPool.java:66)
        at 
de.siegmar.logbackgelf.GelfTcpAppender.sendMessage(GelfTcpAppender.java:194)
        at 
de.siegmar.logbackgelf.GelfTcpAppender.appendMessage(GelfTcpAppender.java:168)
        at 
de.siegmar.logbackgelf.AbstractGelfAppender.append(AbstractGelfAppender.java:101)
        at 
de.siegmar.logbackgelf.AbstractGelfAppender.append(AbstractGelfAppender.java:27)
        at 
ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85)
        at 
ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
        at 
ch.qos.logback.core.AsyncAppenderBase$Worker.run(AsyncAppenderBase.java:302)

{noformat}
Though the logging of the repeated message can be switched off using a 
BrokerLogInclusionRule targeting the BrokerLoggerStatusListener class, it would 
be beneficial to make BrokerLoggerStatusListener logic more flexible, logging 
stacktraces on lower log levels (DEBUG, TRACE) only.


> [Broker-J] BrokerLoggerStatusListener produces repeated stacktraces
> -------------------------------------------------------------------
>
>                 Key: QPID-8694
>                 URL: https://issues.apache.org/jira/browse/QPID-8694
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>    Affects Versions: qpid-java-broker-9.2.1
>            Reporter: Daniil Kirilyuk
>            Priority: Minor
>             Fix For: qpid-java-broker-10.0.0
>
>
> When an exception happens in logger itself, it is handled by 
> BrokerLoggerStatusListener, leading in some cases to repeated messages, e.g.:
> {noformat}
> 2025-04-02T10:35:42,245Z ERROR [AsyncAppender-Worker-graylog] 
> (o.a.q.s.l.l.BrokerLoggerStatusListener) - Unexpected error whilst trying to 
> store log entry. Log messages could be lost.
> java.net.ConnectException: Connection refused
>       at java.base/sun.nio.ch.Net.pollConnect(Native Method)
>       at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:672)
>       at 
> java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:554)
>       at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:602)
>       at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
>       at java.base/java.net.Socket.connect(Socket.java:633)
>       at de.siegmar.logbackgelf.TcpConnection.connect(TcpConnection.java:73)
>       at de.siegmar.logbackgelf.TcpConnection.write(TcpConnection.java:56)
>       at 
> de.siegmar.logbackgelf.GelfTcpAppender.lambda$sendMessage$1(GelfTcpAppender.java:194)
>       at 
> de.siegmar.logbackgelf.pool.SimpleObjectPool.execute(SimpleObjectPool.java:66)
>       at 
> de.siegmar.logbackgelf.GelfTcpAppender.sendMessage(GelfTcpAppender.java:194)
>       at 
> de.siegmar.logbackgelf.GelfTcpAppender.appendMessage(GelfTcpAppender.java:168)
>       at 
> de.siegmar.logbackgelf.AbstractGelfAppender.append(AbstractGelfAppender.java:101)
>       at 
> de.siegmar.logbackgelf.AbstractGelfAppender.append(AbstractGelfAppender.java:27)
>       at 
> ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85)
>       at 
> ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
>       at 
> ch.qos.logback.core.AsyncAppenderBase$Worker.run(AsyncAppenderBase.java:302)
> {noformat}
>  
> Described behavior occurs due to the logging of logger errors (e.g. when 
> graylog server is unavailable). It can be switched off by creating a 
> BrokerLogInclusionRule, e.g. via curl command:
> {code:java}
> curl -d 
> '{"name":"graylog","type":"NameAndLevel","durable":true,"loggerName":"org.apache.qpid.server.logging.logback.BrokerLoggerStatusListener","level":"OFF"}'
>  
> http://<username>:<password>@<hostname>:<port>/api/latest/brokerloginclusionrule/logfile
>   {code}
> This command sets log level OFF (disables all log messages) produced by the 
> class org.apache.qpid.server.logging.logback.BrokerLoggerStatusListener.
> As the repeated error messages significantly increase the log size, the 
> behavior of the BrokerLoggerStatusListener should be changed to log by 
> default only the error message without the stacktrace. When log level DEBUG 
> or TRACE is enabled, the full stacktrace should be logged for the error 
> analysis purpose.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Reply via email to