David,
Thank you for the detailed explanation. I think I'm in a simpler
situation, which does not require the additional protection you've listed.
On 01/17/2014 05:48 PM, David Lang wrote:
On Fri, 17 Jan 2014, Assaf Gordon wrote:
now, with all of this said, let's get back to your situation and think
about what you are trying to defend against.
Still,
I guess I simply do not understand something about rsyslogd with RELP.
1. My client send messages once every second.
2. Assume that the client sent 10 messages.
3. The server recevied (and ack'd) those 10 messages (I see them in the
server log file).
4. I then kill the server.
5. Message #11 could be lost in rsyslogd's queue (relp-ack'd but not
written).
6. Message #12 could (perhaps) be lost in the ethers of the internet,
but it was not received by rsyslogd and not relp-ack'd.
7. At this point, the client side does not receive any more relp-ack's.
8. I restart the rsyslogd server.
9. It takes about 10 more seconds for the client to reconnect to the server.
10. Once the client reconnect, I seen message #40 and all following
messages received by the server (and written to the log).
Messages between #12 and #39 are lost - or at least not delivered to the
server.
BUT,
If I understood the idea behind "RELP" correctly, the client-side
"rsyslogd" should know and detect that those messages were not ACK'd,
hence not delivered.
Where is my mistake?
Thanks again,
-gordon
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
