> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Thursday, October 08, 2009 6:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] Queue System > > On Wed, 7 Oct 2009, Jonathan Bond-Caron wrote: > > > The client 'sends the message over tcp' and actually empties the > queue! > > > > Is this expected behavior? rsyslogd was shutdown 'cleanly' on the > server. > > Shouldn't it force the client to close the TCP connection? > > > > > > > > Using netstat, the two servers are : > > > > > > > > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > > > > tcp4 0 0 client.10514 server..60726 FIN_WAIT_2 > > > > > > > > Proto Recv-Q Send-Q Local Address Foreign Address > > State > > > > tcp 1 36 server:60726 client:10514 > CLOSE_WAIT > > > > > > > > Have I misunderstood something? I've read Rainer's blog and issues > with TCP > > "unreliability" / case of a power failure but don't think this > related > > I think it's the same problem, one side thinks the connection is > closed, > the other doesn't and so the one that doesn't happily sends the data > out. > > try reconfiguring to use relp and things should work as expected. > > > now, I don't know why the close isn't getting through from the one > system > to the other rapidly. is there any sort of firewall in between them?
The close may get through. It is a (kind of) race condition, inside the tcp stack. Assume the following happens (System S being the server, system C being the client): S : closes connection, sends close info C1: rsyslog writes data (not yet sent, but acknowledged by tcp stack) C2: receives close request C3: discards data The race is in C1/C2. In this order, data is lost. If C2 happens before C1, no data is lost. No chance to solve that with plain tcp without app-level acks. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
