[Openais] multiple fd fix for EVT?

Kristen Smith kjsmith at nortel.com
Tue Feb 1 05:18:55 PST 2005


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.

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/openais/attachments/20050201/e89dfc51/attachment-0001.htm


More information about the Openais mailing list