<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">This was an issue with me not adhering to the (obsolete) syslog protocol (<a href="https://www.ietf.org/rfc/rfc3164.txt">https://www.ietf.org/rfc/rfc3164.txt</a>, 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.<div><br></div><div>There is no issue with logback’s layouts or the SyslogAppender.</div><div><br></div><div>However, we would like to benefit from the outstanding issue and associated patch with regard to additional configuration of the SyslogAppender and SyslogStartConverter : <a href="http://jira.qos.ch/browse/LOGBACK-1011">http://jira.qos.ch/browse/LOGBACK-1011</a>, <a href="https://github.com/qos-ch/logback/pull/139">https://github.com/qos-ch/logback/pull/139</a>. These are quite old and I am curious if they are part of any planned releases.</div><div><br></div><div>Thanks.</div><div><br></div><div><br></div><div>We would like to <br><div><div>On Oct 28, 2015, at 8:00 AM, <a href="mailto:logback-user-request@qos.ch">logback-user-request@qos.ch</a> wrote:</div><br><blockquote type="cite">Date: Tue, 27 Oct 2015 12:45:05 -0400<br>From: Jeffrey Olchovy <<a href="mailto:jeffo@tapad.com">jeffo@tapad.com</a>><br>To: <a href="mailto:logback-user@qos.ch">logback-user@qos.ch</a><br>Subject: [logback-user] Truncation of log entry when using a specific<br><span class="Apple-tab-span" style="white-space:pre">        </span>sequence of '}]:' characters<br>Message-ID: <<a href="mailto:C5366591-1C27-40E0-AAC3-48C969030384@tapad.com">C5366591-1C27-40E0-AAC3-48C969030384@tapad.com</a>><br>Content-Type: text/plain; charset=windows-1252<br><br>Hello, I am experiencing an unexpected truncation of part of my log entry when using the SyslogAppender with the following suffixPattern:<br><suffixPattern>foo-service[${HOSTNAME}]: %logger %msg</suffixPattern><br><br>The resulting output takes the form:<br>foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing…<br>foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items.<br><br>Rather than the expected:<br>foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing…<br>foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items.<br><br>If I add spaces between the intended variable ${HOSTNAME} and the square brackets, the log entries render as one would expect:<br>foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing…<br>foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items.<br><br>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?<br><br>Thank you.<br></blockquote></div><br></div></body></html>