nit tests pass when I
>have the patch but it's not guarantee in comparison to a real live use-case.
>
>Gary
>
>On Thu, Jan 21, 2016 at 9:51 AM, Blake Day wrote:
>
>> Looks good to me! Thanks!
>>
>>
>>
>>
>> On 1/20/16, 9:30 PM, "Gary
false;
>+}
>+return true;
> }
>
>-private boolean isMessageEquals(final TlsSyslogFrame frame) {
>-return this.message.equals(frame.message);
>-}
> }
>
>
>Gary
>
>On Wed, Jan 20, 2016 at 6:27 PM, Gary Gregory
>wrote:
>
>
I'm mobile so can't confirm, but utf-8 has multi-byte characters as well.
> On Jan 20, 2016, at 9:32 PM, Gary Gregory wrote:
>
>> On Wed, Jan 20, 2016 at 6:18 PM, Blake Day wrote:
>>
>> I'm not sure on that, but it wouldn't fix the erroneous byt
>public byte[] getBytes() {
>final String frame = toString();
>return frame.getBytes(Charset.defaultCharset());
>}
>
> ?
>
> Gary
>
>> On Wed, Jan 20, 2016 at 4:58 PM, Blake Day wrote:
>>
>> TlsSyslogFrame appears to be miscalculating the
TlsSyslogFrame appears to be miscalculating the message length. According to
RFC5425, the message length must be the octet count of the SYSLOG-MSG in the
frame. Though the variable below is aptly named messageLengthInBytes, it is
assigned the value from message.length() (where message is a Str
n, so it isn’t dying. You should still be able to send more
>messages.
>
>> On Jan 19, 2016, at 5:17 PM, Blake Day wrote:
>>
>> I’m having trouble getting additional debug messages, but I did get the
>> following logs with immediateFail=true on the SocketAppender
ou enable the debug logging so we can see what is happening in the
>Appender?
>
>Ralph
>
>> On Jan 19, 2016, at 1:32 PM, Blake Day wrote:
>>
>> Sorry, on further investigation, it appears that the thread does not die.
>> But the subsequent log messages
reconnectionDelayMillis, but nothing seems to have the effect I want.
On 1/19/16, 2:36 PM, "Blake Day" wrote:
>I’m using SocketAppender to log to syslog-ng.
>
>
>When logging a message that exceeds 8192 bytes (a syslog-ng setting),
>syslog-ng gives an error and closes the
I’m using SocketAppender to log to syslog-ng.
When logging a message that exceeds 8192 bytes (a syslog-ng setting), syslog-ng
gives an error and closes the connection. What happens immediately after is
unclear, but it appears that the java thread just dies silently. The thread
itself is a qu
;
>> > On Jan 18, 2016, at 6:24 PM, Gary Gregory
>> wrote:
>> >
>> > Hm, yeah, you cannot pass a layout to a SyslogAppender. Dead end there.
>> >
>> > Gary
>> >
>> > On Mon, Jan 18, 2016 at 5:02 PM, Blake Day > bl...@chewy.c
At that time we didn’t support TLS, so I wasn’t adding a
>TLSSyslogFrame. I don’t recall having any problems with that or with rsyslog.
>
>Ralph
>
>> On Jan 18, 2016, at 5:42 PM, Gary Gregory wrote:
>>
>> What about using a with a ?
>>
>> Gary
>>
So you mean a ? The layout is “hardcoded” on SyslogAppender.
On 1/18/16, 7:42 PM, "Gary Gregory" wrote:
>What about using a with a ?
>
>Gary
>
>On Mon, Jan 18, 2016 at 3:17 PM, Blake Day wrote:
>
>> It was worth a look, but no. SocketAppender creates an
It was worth a look, but no. SocketAppender creates an SslSocketManager when
protocol = SSL.
On 1/18/16, 5:46 PM, "Gary Gregory" wrote:
>I think you might be able to "cheat" by saying protocol="SSL" on the
>appender...
>
>Gary
>
>On Mon, Ja
Hi all,
We are trying to achieve RFC5424 message formats over TCP transport without
TLS.
As you may know, SyslogAppender uses an instance of Rfc5424Layout to provide
the logging layout. That layout takes a parameter called
“useTlsMessageFormat”, which SyslogAppender sets based on whether TL
14 matches
Mail list logo
