On 01/17/2014 04:57 PM, Radu Gheorghe wrote:
I think the most probable cause is that the lost messages were in the
in-memory queue, which got wiped during restart. To fix that, you'd have to
make it disk-assisted and set queue.saveonshutdown to yes. I think you'll
find the details in those two links:
http://www.rsyslog.com/doc/queues.html
http://www.rsyslog.com/doc/node32.html
I might have a basic mis-understanding of the RELP features.
When sending messages from the client like so:
--
$ for i in $(seq 100) ; do echo "Message $i" ; sleep 1 ; done | \
logger -u /tmp/client.sock -d
--
Only one message is sent every second.
On the server side, I use "tail -f server.log", and I see the message
appear immediately.
So when I kill the server, it theoretically can have at most one message
"in the queue but not written to a file".
Is that a correct assumption?
Beyond that point, the server process is killed, and no new message can
enter the memory queue (they could be stuck in the server's kernel TCP
queue, perhaps, but not reach the rsyslogd applicatoin).
Since the server did not receive any more messages, it could not have
ACK'd any messages to the client - which is what RELP is all about
(correct?).
So the client should be able to tell that several messages were not
received.
Yet in my testing, after restarting the server rsyslogd, more than 20
messages are missing (meaning over 20 seconds of the client-side
rsyslogd sending data).
Do I need to enable some queuing on the client-side as well?
Thanks,
-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.
