[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