[Openais] multiple fd fix for EVT?

Steven Dake sdake at mvista.com
Tue Feb 1 12:36:30 PST 2005


On Tue, 2005-02-01 at 06:18, Kristen Smith wrote:
> Steve,
> 
> My thoughts on going to B are that, for me, that is lower priority
> than the recovery work. Is the recovery work being preempted by the B
> work or is it going on simultaneously? For me, B is something I can
> wait on, but the recovery code is not. Between 188 and B, I would
> rather see 188 be done first.
> 

recovery work would be parallel to B implementation.  Ie: I'd work on
recovery and mark could work on the B evt.  This would leave ckpt at A
until we get recovery done, but moving to a B spec is not too much work
(except for AMF).

I understand your comments about 188.  So here is our current (adhoc)
plan of actions:

fix segfault in assembly - defect 204
fix sq assert
recovery base - defect 206, defect 176
recovery of evt - defect 40, 199
recovery of ckpt - defect 41
multiple fds per api - defect 188
B spec

I think this means Mark can work on the B spec implementation of evt
while I sort out the recovery base (206, 176).  Once that is done,
whether evt B is done or not, we can do 40, 199, and 41.

Working recovery and multiple fds parallel is difficult because the amf
portion of the multiple fds patch is not complete.  But we could merge
ckpt, evt, clm for now, and let amf hang until we finish recovery.

Is anyone on the list using AMF at the moment, and could they stand it
to be broken in bitkeeper for 3-4 weeks?

Thanks
-steve

> One other thing - I have seen this come out a few times in the past
> few days:
> 
> aisexec: ../include/sq.h:102: sq_item_add: Assertion
> `sq->items_inuse[sq_position] == 0' failed.
> 

yes i have seen this too...  We will get to this one once we get the
fragmentation and assembly work sorted out.

> I seem to recall that this is related to the fragmentation/reassembly
> work that you guys are doing. Is that correct, or does this need to be
> looked at further?
> 
> Thanks,
> Kristen
> 
> -----Original Message-----
> From: Steven Dake [mailto:sdake at mvista.com] 
> Sent: Monday, January 31, 2005 6:46 PM
> To: Smith, Kristen [NGC:B675:EXCH]
> Cc: Openais List
> Subject: Re: [Openais] multiple fd fix for EVT?
> 
> 
> On Mon, 2005-01-31 at 16:36, Kristen Smith wrote:
> > Steve/Mark,
> > 
> > A while back you had mentioned that you planned on adding 2 fds per 
> > service (one for responses and one for dispatches). Today I ran into
> a 
> > problem which looks to be caused by 1 fd for the evt service. I was 
> > seeing a race condition where I was trying to do an EvtPublish right
> > when an EVT message was coming in from another node. I believe what 
> > was happening is that the request/response in Publish was getting
> the 
> > new EVT message in the response instead of the publish request 
> > response (I hope that makes sense). Basically, since the same fd is 
> > being used by both the publish and the dispatch, it appears that 
> > responses can come in out of order.
> > 
> > To get me back up and running, I added a few hacks to lib/evt.c, but
> I 
> > am sure they are not what is finally intended. So,I was curious if 
> > converting to multiple fds was still on the plate for the evt
> service 
> > or not.
> > 
> > Thanks,
> > Kristen
> > 
> 
> Kristen
> yes.  I would have done this already but I was very displeased with
> the previous protocol's stability and needed to correct that first.
> 
> We should decide if we will do B.01.01 specs first or the transition
> to defect 188.  I think we can do the 188 work first or B spec work
> first.
> 
> >From your perspective, it might be better to have the B
> implementation
> sooner then defect-188 fixed.  Could you comment on this?  For the
> developers, this is a little more painful because we will have to sort
> out the library dual fd code again.  The server side should remain the
> same for the clm, ckpt, and evt services that are completed thus far.
> 
> Thanks
> -steve
> 
> 
> > 
> >
> ______________________________________________________________________
> > _______________________________________________
> > Openais mailing list
> > Openais at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/openais
> 
> 




More information about the Openais mailing list