Open onkar-dhawade opened 9 years ago
Apparently there is a similar situation with messages, that contain russian characters.
This is a bug in org.syslog4j
cause by it taking the message length in characters, and then treating it as if it was a byte length. There is a fork of syslog4j called syslog4j-graylog2. It's almost a drop-in replacement (everything just moved to a different package). It also seems to support configuring the hostname that is transmitted so the workaround of providing it via the layout isn't needed.
Logs are being sent from the application to remote server (CentOS) on rsyslog using Papertrail Syslog4jAppender (https://github.com/papertrail/logback-syslog4j).
Please see below the rsyslog details: rsyslogd 7.4.7, compiled with: FEATURE_REGEXP: Yes FEATURE_LARGEFILE: No GSSAPI Kerberos 5 support: Yes FEATURE_DEBUG (debug build, slow code): No 32bit Atomic operations supported: Yes 64bit Atomic operations supported: Yes Runtime Instrumentation (slow code): No uuid support: Yes
Rsyslog with English characters:
<14>, user.info, 2015-06-18T15:13:31+05:30, SERV1 ,INFO ,PwxfVHYxAcV6V2EqYPf55247, MERCH01, TR9, PTYPE, PSP, UP00000, Successful Transaction, , 2015-06-18T09:43:30Z, 2015-06-18T09:43:31Z, SUCCESS Rsyslog with Japanese characters: <14>, user.info, 2015-06-19T12:06:24+05:30, SERV1 ,INFO ,M9z74Bw9MvI7DadZDVSJ5273, MERCH01, TR9, PTYPE, PSP, UP00000, 成功したトランザクション, , 2015-06-19T06:36:18Z, 2015-06 With English only characters, I was able to log more than 1000 characters. Even the Japanese characters are displayed correctly but the last few characters gets truncated.