[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipropd-master CLOSE_WAIT problem
Balazs GAL <balsa@rit.bme.hu> writes:
> 2003-03-19, sze keltezéssel Love ezt írta:
>> Balazs GAL <balsa@rit.bme.hu> writes:
>>
>> > If an perviously connected replica disconnect from ipropd-master, then
>> > ipropd-master will not close the used tcp socket until the replica
>> > reconnect again.
>> > Because it the the tcp socket will be in CLOSE_WAIT state.
>> > Because it the select func in every loop will report this socket
>> > as activ and will never sleep, so ipropd-master will eat all the
>> > CPU time until the replica reconnect.
>>
>> So, ignoring slave that are dead in select processing will also solve the
>> problem, this way I don't need to add another extra flag.
>
> Maybe I'm wrong, but krb5_read_priv_message can only return
> HEIM_ERR_EOF?
krb5_read_priv_message can return any error/errno.
> Should we really close the conection if it return other than 0 or
> HEIM_ERR_EOF? The connection is unusable after a non null return?
Its not unusable, the client either sent a too short message or it was
invalid content, just close the connection and have the client reconnect.
> I think, that SLAVE_F_DEAD flag is only for registration purpuses (e.g
> looks cool in slaves-stats;).
Well, its the same thing, SLAVE_F_DEAD == client dead and ipropd_master should
consider it dead and ignore it.
> On the whole, the incremental propagation works now well. Many thanks
> for it. But as I noticed I should restart slaves in every 15 or 30
> minutes, because it doesn't handle network outages well (it will keep
> the connection open even if the master has closed it in the network
> outages), and check often (e.g in every 2 minutes) if it run or not.
Oh, ok. So there should be a pinging from the server, and if the server
doesn't send or if the client isn't responding, the connection should be
considered dead.
Love