[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a QE &/or QM request



Henrik Nordberg wrote:
> 
> "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 was worried about if the QO called done() on an executing query. This is 
possible but currently coded to be used only for un_submitted queries.  
The QO doesn't talk to the QM but the Client code's "GC" factory 
(GCA_Resources) does.

> 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.
> 

I think so too with the caveat that the QO should not [be able to]
call "done()" on any executing queries - so that the QE doesn't 
prematurely flush its memory of the query.  The QO does need to call done()
on unsubmitted 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.
>
True - as long as the QE knows about all the active queries.
 
> > 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.
>

This was again refering to the case where the QO called done()
while the query was executing.  This done() doesn't abort 
the query but the QE would loose memory of it.  
 
> > 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.
> 


Thanks, Jeff
begin:vcard 
n:Porter;R. Jeff
tel;fax:516-344-4206
tel;work:516-344-7953
x-mozilla-html:FALSE
org:Brookhaven National Lab
version:2.1
email;internet:porter@bnl.gov
adr;quoted-printable:;;=0D=0APhysics Department,=0D=0ABld 510A;Upton;NY;11973;
x-mozilla-cpt:;15856
fn:R. Jeff Porter
end:vcard