September 2016 - logback-user

Logback => TLS/SSL => Syslog ?
by Otis Gospodnetić 21 Feb '19

21 Feb '19

Hi, Does Logback support sending logs to Syslog servers via TLS/SSL? I have a feeling Logback doesn't have a SyslogAppender that can send data using TLS. I say that because I don't see a mention of "syslog" on http://logback.qos.ch/manual/usingSSL.html and I see http://jira.qos.ch/browse/LOGBACK-890 that mentions TLSSyslogAppender, but it looks like this never ended up in Logback. I've only found it committed here: https://github.com/balabit/logback/commit/e0d89de2536e0925a6c816a50793f6a74… Could anyone please clarify? Thanks, Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/

2 1

Seeking help with Logback-related race condition in Dropwizard
by Evan Meagher 24 Sep '16

24 Sep '16

Greetings Logback community, I'm one of the maintainers of Dropwizard, a Java REST service library. We're dealing with an race condition that may have something to do with Logback and I wanted to reach out to see if our issue smells like anything the Logback team has encountered before. We've been trying to diagnose a small handful of related bugs that all seem to stem from a race condition somewhere within the interaction between Jetty's request-handling lifecycle, Logback's RequestLogImpl, and Logback's async appender functionality. My best assessment of the issue is as follows. Jetty defines a Request class to encapsulate state specific to a single request (i.e. HTTP headers, query parameters, etc). Jetty servers reuse instances of this Request class for each connection (presumably in order to reduce memory pressure), and thus requests have to be recycled <http://download.eclipse.org/jetty/9.3.11.v20160721/apidocs/org/eclipse/jett…> for each individual HTTP request. We seem to get into trouble when Logback's RequestLogImpl is used in conjunction with AsyncAppenderBase. `AccessEvent# prepareForDeferredProcessing` <https://github.com/qos-ch/logback/blob/master/logback-access/src/main/java/…> , which populates the event with request data, is invoked by both of these codepaths. Could it be possible that Jetty's use of a mutable Request object per connection could be getting in the way of asynchronous request logging by Logback? For the complete background, the bug(s) span the following Dropwizard issues: - https://github.com/dropwizard/dropwizard/issues/1672 - https://github.com/dropwizard/dropwizard/issues/1686 - https://github.com/dropwizard/dropwizard/issues/1699 Unfortunately, we don't have a single representative test case to illustrate the issue. In this latter GitHub issue (#1699), Nick Babcock and I traded notes back and forth as we spelunked through Dropwizard, Jetty, and Logback trying to root out the issue, and found that forcing synchronous request logging prevented the inconsistent behavior. Any guidance on Logback usage related to this would be a very helpful. Thanks, -- Evan Meagher

1 0

Re: [logback-user] jira down; ReconfigureOnChangeTask bug
by Stefan.Brozinski＠materna.de 19 Sep '16

19 Sep '16

Ah, now that Jira is up I can see that an issue had already been created. http://jira.qos.ch/browse/LOGBACK-1194 Von: logback-user [mailto:logback-user-bounces@qos.ch] Im Auftrag von ceki Gesendet: Freitag, 16. September 2016 20:44 An: logback users list <logback-user(a)qos.ch> Betreff: Re: [logback-user] jira down; ReconfigureOnChangeTask bug Jira should be up now. Please create a jira issue for the scanPeriod bug. I'll look into it on Tuesday as I am currently traveling. -- Ceki -------- Original message -------- From: Stefan.Brozinski(a)materna.de<mailto:Stefan.Brozinski@materna.de> Date: 2016/09/16 18:41 (GMT+01:00) To: logback-user(a)qos.ch<mailto:logback-user@qos.ch> Subject: [logback-user] jira down; ReconfigureOnChangeTask bug Dear all, just in case you haven’t noticed: jira.qos.ch is currently down (http 503). I would also like to point out that the git commit 1518573 introduced a bug. Having only the „scan“ attribute in the logback configuration without an additional „scanPeriod“ attribute does NOT activate the ReconfigureOnChangeTask. So currently you need to have something like scanPeriod=“60 seconds“ in your logback.xml if you want to have your configuration changes being picked up without having to restart your process. This might also be the reason for the problems that were recently observed by Gaël Marziou. Gaël, does it help to add a scanPeriod to your configuration? Best regards Stefan

1 0

Re: [logback-user] jira down; ReconfigureOnChangeTask bug
by ceki 16 Sep '16

16 Sep '16

Jira should be up now. Please create a jira issue for the scanPeriod bug. I'll look into it on Tuesday as I am currently traveling. --Ceki -------- Original message -------- From: Stefan.Brozinski(a)materna.de Date: 2016/09/16 18:41 (GMT+01:00) To: logback-user(a)qos.ch Subject: [logback-user] jira down; ReconfigureOnChangeTask bug Dear all, just in case you haven’t noticed: jira.qos.ch is currently down (http 503). I would also like to point out that the git commit 1518573 introduced a bug. Having only the „scan“ attribute in the logback configuration without an additional „scanPeriod“ attribute does NOT activate the ReconfigureOnChangeTask. So currently you need to have something like scanPeriod=“60 seconds“ in your logback.xml if you want to have your configuration changes being picked up without having to restart your process. This might also be the reason for the problems that were recently observed by Gaël Marziou. Gaël, does it help to add a scanPeriod to your configuration? Best regards Stefan

1 0

jira down; ReconfigureOnChangeTask bug
by Stefan.Brozinski＠materna.de 16 Sep '16

16 Sep '16

Dear all, just in case you haven't noticed: jira.qos.ch is currently down (http 503). I would also like to point out that the git commit 1518573 introduced a bug. Having only the "scan" attribute in the logback configuration without an additional "scanPeriod" attribute does NOT activate the ReconfigureOnChangeTask. So currently you need to have something like scanPeriod="60 seconds" in your logback.xml if you want to have your configuration changes being picked up without having to restart your process. This might also be the reason for the problems that were recently observed by Gaël Marziou. Gaël, does it help to add a scanPeriod to your configuration? Best regards Stefan

2 1