[logback-user] Truncation of log entry when using a specific sequence of '}]:' characters

Jeffrey Olchovy jeffo at tapad.com
Wed Oct 28 14:21:25 UTC 2015


This was an issue with me not adhering to the (obsolete) syslog protocol (https://www.ietf.org/rfc/rfc3164.txt, section 4.1.3). Our TAG part of the message was greater than 32 characters and was being truncated. In the example, I used a false string ‘foo-service’. In reality, it was much longer (service-xxxxxxxxxxx). That, combined with the 12 character hex ‘pid’ and decorating brackets, pushed us over the limit. It rendered correctly with the spaces surrounding the hex characters since the whitespace violated the pattern that would attempt to identity (and subsequently, truncate) the TAG.

There is no issue with logback’s layouts or the SyslogAppender.

However, we would like to benefit from the outstanding issue and associated patch with regard to additional configuration of the SyslogAppender and SyslogStartConverter : http://jira.qos.ch/browse/LOGBACK-1011, https://github.com/qos-ch/logback/pull/139. These are quite old and I am curious if they are part of any planned releases.

Thanks.


We would like to 
On Oct 28, 2015, at 8:00 AM, logback-user-request at qos.ch wrote:

> Date: Tue, 27 Oct 2015 12:45:05 -0400
> From: Jeffrey Olchovy <jeffo at tapad.com>
> To: logback-user at qos.ch
> Subject: [logback-user] Truncation of log entry when using a specific
> 	sequence of '}]:' characters
> Message-ID: <C5366591-1C27-40E0-AAC3-48C969030384 at tapad.com>
> Content-Type: text/plain; charset=windows-1252
> 
> Hello, I am experiencing an unexpected truncation of part of my log entry when using the SyslogAppender with the following suffixPattern:
> <suffixPattern>foo-service[${HOSTNAME}]: %logger %msg</suffixPattern>
> 
> The resulting output takes the form:
> foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing…
> foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items.
> 
> Rather than the expected:
> foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing…
> foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items.
> 
> If I add spaces between the intended variable ${HOSTNAME} and the square brackets, the log entries render as one would expect:
> foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing…
> foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items.
> 
> Are there any known issues or workarounds that either will prevent or resolve this behavior? Or, alternatively, does this smell like something downstream of logback and more at the syslog level?
> 
> Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20151028/aa465747/attachment.html>


More information about the logback-user mailing list