Hi Jan,
Jan Harkes wrote:
What happens is that the client detects whether a server is up or down
based on the existence of a callback connection. So when the client
sends a probe, the server pings back on the callback connection.
Yepp, seen that from the log
However backfetches are using the same connection, and your backfetch is
taking very long. So the server is unable to send the ping back to the
client. This shouldn't be a problem because the server should be
responding with RPC2_BUSY which will make the client wait an extra 15
seconds or so. I guess at some point the client did give up, returned
ETIMEDOUT and disconnected.
Hmm. How is this RPC2_BUSY supposed to work.
Should this ObtainWriteLock somehow timeout? Which thread should
send the BUSY reply?
As far as I can see, the client sends the Probe several times on
the RPC2 level, without getting *any* reply.
And the Server itself also 'looses faith' in the client, some
seconds after hanging in this lock.
It drops the callback-conn then.
long, it should have been broken up by the client.
This is actually a
known bug (introduced somewhere between 6.0.9 and 6.0.12), the fix is
fairly simple, just removing an unnecessary test. I've attached the
patch.
OK, will try that.
And arguably, the client shouldn't even have to probe the server because
clearly there is still traffic between the two. But that is more of an
optimization and not really a correctness issue.
Hmm: I don't know. In my tests I explicitly stimulated the
'Probe' by running
cfs cs
But Venus itself pings also automatically after a certain time (150s),
and this will take down the connection also. Therefore monitoring
the activity on the client-server connection for all activity
and stopping explicit probes, when venus received other traffic seems
to be logical.
This is actually not a reintegration write lock, this is caused by the
fact that there is only a single RPC2 connection from the server to the
client, so it can only do one thing at a time. Fetch a file, or send a
callback probe.
You mentioned, that clients should break up their store OPs.
Can they break up the transfer-size below file-size?
Or do they have to transmit at least one file completely.
I think this matters for the ISO-Images.
Thanks for your help
Martin
--
+-[Martin Ginkel]-------------[mailto:mginkel(at)mpi-magdeburg.mpg.de]-+
| MPI Magdeburg, Zi S2.09 Sandtorstr. 1, D-39106 Magdeburg, Germany |
| What is this talk of 'release'? We are Klingons. Our software |
| 'escapes' leaving a bloody trail of designers and quality assurance |
+-[tel/fax: +49 391 6110 482/529]----[http://www.mpi-magdeburg.mpg.de]-+
