Query termination clariffication

[Arie Shoshani <arie@math.lbl.gov>]

Sorry, but I must have not been clear, and that cause all this discussion
between Henrik, Jeff, and Alex.  Let me try to explain the intension again.

"Abort" issued by the QO means terminate that query, i.e. get rid of
it completely in the middle of executing the query as if it is all
done.  Thus, the QE can clear the query from its cache,and notify the
QM.  The QM puts the query in the "done list", and in addition (I
neglected to say that in my previous msg) put all the files that have
been cached for that query on the "can be purged list" (provided that
no other query uses it).  To any further requests (both "request" and
"retrieve")from EIs for that query, the QM responds "no more files
for you".  (Now, we may consider keeping track of aborts for another
reason: we may want the QM to keep the "abort" status for logging and
monitoring purposes.)

"Done" issued by the QO means, on the other hand, that the QO does
not need to communicate with the QE any further.  It may or may not
have EIs still active.  In this case, the QE can clear the query from
the cache, but does NOT notify the QM. Thus the QM continues to
cache files for all EIs associated with this queries till they got
the last file.

Another issue raised is whether the QM needs to keep track of queries
that are aborted.  We concluded that this is not necessary.  It is
sufficient to put that query in the QM "done list" (and mark all
cached files as "can be purged").  The reason that this is sufficient
is that the EIs for this query will not get any more files (because
they are on the "done list"), and eventually terminate.

As for crashes, that's another matter.  Henrik's suggestion to detect
a crash sounds good.  But, we still need a time out "are you alive"
mechanism for the QM to see if an EI is just slow or not responding
(maybe it did not crash, just sitting in a loop).

I hope this clarifies the issues.  Are there still any holes?

Arie.