On Wed, Jan 14, 2004 at 10:57:11AM -0500, Greg Troxel wrote:
> I'm getting a lot of 'no waiters' (client across 28.8 line is
> hoarding, and it seems no longer to be doing sha1 getattrs).

When a client connects it tries a SHA1 getattr, if that returns an error
it will fall back to the old getatts. I have to look whether any generic
error triggers this or only the ones we really care about (EOPNOTSUP or
EINVAL or something).

> the client got
>  10:41:11 Reintegrate: u.gdt, 1/1 records, result = Unknown error: 198
> but is happily 'Connected'.

198 is the error that is returned when trying to reintegrate on an
existing conflict. But the 1/1 means that we did manage to reintegrate
all outstanding records. I wonder whether there is an off-by-one problem
here, how else could we get an error and still succeed.

This could be the lead to the cml::thread errors that have been reported
several times recently.

> Also, there seems to be a missing fflush.  The file really does end
> with a d.
> 
> No waiters, dropped incoming sftp packet
...

Possibly, it is more of an informational warning message than an error. 
I added it to test a 'theory', this happens every time a sftp packet
arrives, but there isn't a thread actively waiting for it. I it should
only happen on the 'active' side of the connection, when data is pushed
from the passive side to the active side. In normal terms, this happens
when a client is using ViceStore to send data to the server.
(or when the reintegration log is sent as a side-effect of the
ViceReintegrate rpc)

It really isn't critical, except that as a result the client will be
told to resend the packet although we technically did receive it but
weren't ready to deal with it just yet. I would expect this to occur
more on a fast connection than on a 28.8 connection though.

Jan