Re: a QE &/or QM request

[Henrik Nordberg <hnordberg@lbl.gov>]

"R. Jefferson Porter" wrote:
> 
> It may be that the best server to provide this interface is the QM since 
> an executing query could have been flushed from the QE memory with
> a done() call.

done() is called by QM. If QM calls done, would it still keep the query alive?
Is the QO currently talking to the QM?
I think it makes more sense to put this functionality into the QE.
QE was supposed to be the point of contact for info about queries.

> Alex Sim wrote:
> >
> > Extracting those info could not harm QM at all...
> > Let me know what you have in mind for struct type.
> 
> Great.  There are, I think, 2 holes that would need to
> be filled - so it may be something we'd like to postpone
> doing.
> 
> Hole 1:  The QM doesn't know about orphaned SM_UNSUBMITTED
> queries. This shouldn't happen but can if the QO destructor
> is not called due to a usercode crash or due to mishandling
> the CORBA reference count. One way out of this is for
> the QO to request the list from the QE and the QE requests
> the executing list from the QM & concats this to an
> unsubmitted list within the QE that is then returned to
> the QO. (whew)

This isn't an issue if QE is doing the work.
 
> Hole 2:  The QE cannot abort a query that it has flushed
> from its memory.  For these cases, we could allow the
> QE pass the "abort(token)" onto the QM when the QE doesn't
> doesn't recognize the token.

QE should be changed to recognize the difference between a
non-existant query and one that was aborted or completed.
 
> In any event, I'll put together a struct that we'd like
> to have and we can discuss such details as time allows.
> Maybe we should take up this admin item in a more general
> administration discussion at the April meeting.

Regards, Henrik 
_________________________________________
Henrik Nordberg       <hnordberg@lbl.gov>
Scientific Data Management Research Group
Lawrence Berkeley National Laboratory