Re: Query termination

[Henrik Nordberg <HNordberg@lbl.gov>]

Alex Sim wrote:
> 
> R Jeff Porter x6983 wrote:
> >
> > My thoughts from our discussions are:
> >
> >   b) done.   Again I concur with Arie & Henrik but do have one
> >      question which raises the issue of a point-of-contact for the
> >      query.  I think we've assumed that "done" is issued only at the
> >      the end of the process. However, suppose I am "done" with the QO
> >      and tell the QE this ... e.g. in the QO destructor.
> >      EI's may still be working on files - could they still get more files?
> 
> What I understood about "done" is that it happens when EI releases all
> the files.

That is true for the QM. There is also a call to QE::done() when the
QO destructs.

> If the user
> says "done" during the process, it actually means "abort". When he/she
> aborts
> the query, he/she will not get any more files.

We don't have to let the user invoke done(). We can put it in ~QO().
 
> >      Then if I wished to abort the query, how could I do it? I guess
> >      the answer is that I couldn't do it.
> 
> When you abort, just abort... I think.

You would not be able to abort() it because the query token isn't valid
any more. This problem disappears if we hide done() from the user. It
is really only meant as a means for the QO to let the QE know that it
can free resources associated with a query.

> However, it raises one quetion to me: When the EI hasn't release all the
> files,
> but the user aborted the query, then can those "unreleased" files be
> purged
> when necessary?

Yes.
 
> >      Similarly, what would happend if I,
> >         query->pause();
> >         ....
> >         query->done();
> >      without doing a resume or abort before done. The QM would not know that
> >      the query could never be resumed.  The simple solution
> >      here would be to only allow "done" on an executing query.

Or not to expose done() in the UI.

> >      And all such queries must process until finished. Otherwise,
> >      perhaps both the user-codes and QE will need to be able to
> >      re-construct the query based on some history file in order to
> >      abort/resume wayward/paused jobs.
> 
> Again, this "done" means kind of "abort" that the user does not want the
> query to
> be processed all the way to the end, but not exactly the same as
> "abort". In this
> case, something needs to be done to wait for the current process to be
> finished.

This triggered me to think about what happens when the user code
crashes. Then done() might not be called.
This is a problem. One way to solve it is to create a thread in 
the QO and one in QE and establish a CORBA calls that doesn't return.
Now, when the user code crashes (and brings the QO with it, I assume?),
then the ORB throws a COMM_FAILURE exception that the QE thread can
catch and delete the query.
An alternative is to rely on the timeout mechanism between the QM and 
the EI. When a query times out, QM could call QE->done() for that
query.

Thoughts?

	- Henrik
___________________________________________________________
Henrik Nordberg <HNordberg@lbl.gov> http://nordberg.lbl.gov
Scientific Data Management Research Group
Lawrence Berkeley Laboratory