RSPlib Discussions

Text archives Help


Re: [RSPlib-Discusssion] fail-over problems


Chronological Thread 
  • From: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>
  • To: "Thomas Dreibholz" <dreibh AT irmgard.exp-math.uni-essen.de>, <rsplib-discussion AT sctp.de>
  • Subject: Re: [RSPlib-Discusssion] fail-over problems
  • Date: Wed Oct 2 16:32:01 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>

In the last mail, you proposed me to make the following changes (among the
others):

--------------
To locate this problem, go to condition.cc, Condition::addParent() and add
the following line:
printf("adding parent %p (%s) to %p
(%s)",(void*)parent,parent->getName(),(void*)this,this->getName);
Go to Condition::removeParent() and add the following line:
printf("removing parent %p (%s) to %p
(%s)",(void*)parent,parent->getName(),(void*)this,this->getName);
--------------

But, it reports that the variable "parent" is not declared. It is probably
the same with "this". Did you mean some other variables instead of these
two?

Best regards,
Marjan



----- Original Message -----
From: "Thomas Dreibholz"
<dreibh AT irmgard.exp-math.uni-essen.de>
To: "Marjan Bozinovski"
<marjanb AT cpk.auc.dk>;
"Thomas Dreibholz"
<dreibh AT exp-math.uni-essen.de>;

<rsplib-discussion AT sctp.de>
Sent: Wednesday, October 02, 2002 2:26 PM
Subject: Re: [RSPlib-Discusssion] fail-over problems


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Dienstag, 1. Oktober 2002 15:21, Marjan Bozinovski wrote:
> > Hi Thomas,
> >
> > I am sorry to be so delayed, from 21st of September until yesterday I
was
> > out of office and I was not able to check my e-mail. Now, I am back and
I
> > did according to the suggestions in your last mail. And here is what
I've
> > got.
> >
> > First, I set timeout.tv_sec to 20 seconds and realized that it is
> > definitely the select timeout that wakes up the ext_select because the
> > debug line "select: wake-up" shows up immediately after its expiration.
> >
> > Second, I recompiled the libraries as you described and this is the
debug
> > output I get:
> >
> > -----------------
> > select: adding FD 0 (0) with mask $0003
> > select: registering user callback for socket 0...
> > Sending Break via break pipe...
> > F0008: User Callback, mask=$1
> > Break via break pipe received
> > Break Pipe: 1 calls
> > select: adding FD 1020 for read
> > select: adding FD 1020 for except
> > select: adding FD 1021 for read
> > select: waiting...
> > A0003 S00: Data Arrive Notification, Length = 392
> > broadcast: SCTPAssociation::InQueue
> > broadcast: SCTPAssociation::ReadUpdateCondition
>
> The last 2 lines are caused by Condition::broadcast(), which is called for
the
> associaton's input queue. Then, since it has the parent
> SCTPAssociation::ReadUpdateCondition, Condition::broadcast() is called for
> Condition::broadcast().
> But here, SCTPAssociation::ReadUpdateCondition should have another parent
> which is set in sctpsocketwrapper.cc, collectSCTP_FDs() by the following
> code:
> if(tdSocket->Socket.SCTPSocketDesc.SCTPAssociationPtr != NULL) {
> selectData.ConditionArray[selectData.Conditions] =
>
tdSocket->Socket.SCTPSocketDesc.SCTPAssociationPtr->getUpdateCondition(type)
;
>
> The pointer to the condition (SCTPAssociation::ReadUpdateCondition) is
> obtained from the SCTPAssociation object.
>
> #ifdef PRINT_SELECT
> if(selectData.ConditionArray[selectData.Conditions]->peekFired()) {
> cout << "collectSCTP_FDs: condition already fired" << endl;
> }
> #endif
>
> selectData.ParentConditionArray[selectData.Conditions] = &condition;
>
selectData.ConditionArray[selectData.Conditions]->addParent(selectData.Paren
tConditionArray[selectData.Conditions]);
>
> A new parent is set for SCTPAssociation::ReadUpdateCondition is set, here:
> selectData.ReadCondition (named "ext_select::ReadCondition").
> selectData.ReadCondition itself has the parent seletData.GlobalCondition
> (named "ext_select::GlobalCondition").
>
> selectData.ConditionFD[selectData.Conditions] = fd;
> selectData.ConditionType[selectData.Conditions] = type;
> selectData.Conditions++;
> return(0);
> }
>
> seletData.GlobalCondition finally is the condition ext_select waits for.
When
> SCTPAssociation::InQueue is fired, SCTPAssociation::ReadUpdateCondition is
> fired. This should fire ext_select::ReadCondition and this
> ext_select::GlobalCondition. Therefore, it seems that there is somewhere a
> problem with the condition's parent setting. To locate this problem, go to
> condition.cc, Condition::addParent() and add the following line:
> printf("adding parent %p (%s) to %p
> (%s)",(void*)parent,parent->getName(),(void*)this,this->getName);
> Go to Condition::removeParent() and add the following line:
> printf("removing parent %p (%s) to %p
> (%s)",(void*)parent,parent->getName(),(void*)this,this->getName);
> Go to condition.icc, Condition::broadcast() and add the following 3 lines
at
> the specified position:
> set<Condition*>::iterator iterator = ParentSet.begin();
> // -------- Add this:
> if(iterator == ParentSet.end()) {
> cout << "No parents!" << endl;
> }
> // --------
> while(iterator != ParentSet.end()) {
>
> Go to sctpsocketwrapper.cc, collectSCTP_FDs() and add the following lines
at
> the specified position:
> selectData.UserCallbackFD[selectData.UserCallbacks] = fd;
> if(tdSocket->Socket.SCTPSocketDesc.SCTPAssociationPtr != NULL) {
> selectData.ConditionArray[selectData.Conditions] =
>
tdSocket->Socket.SCTPSocketDesc.SCTPAssociationPtr->getUpdateCondition(type)
;
> // -------- Add this:
> printf("Condition for FD %d, type %d is
>
%p\n",(int)fd,(int)type,(void*)selectData.ConditionArray[selectData.Conditio
ns]);
> // --------
>
> Please note the FreeBSD/pthread comments below, recompile and reinstall
the
> socketapi (with gmake clean, to ensure complete recompilation!), recompile
> rsplib (also with gmake clean) and try your program again.
>
>
>
> > select: wake-up
> > Condition 0 (Type 1020, FD 134880283) not fired
> > Condition 2 (Type 1020, FD 134880283) not fired
> > Condition 0 (Type 1021, FD 134880283) not fired
> > -----------------
> >
> > What confuses me is actually the fact that my client application is
> > essentially very similar to the program examplepu.c. It uses the same
> > sequence of functions:
> > -------
> > connectToPoolElement();
> > sendToPoolElement(buffer);
> > rspSelect();
> > -------
> >
> > The difference is that mine is an external application with respect to
the
> > rsplib and socketapi.
>
>
> Make sure, that *all* your sources are compiled with the options
> "-D_REENTRANT -D_THREAD_SAFE" and that you also set the compiler option
> - -pthread for FreeBSD. Do not link your program with a pthread library,
it is
> already included in the libc for FreeBSD.
>
>
> Best regards
> - --
> =======================================================================
> Dipl.-Inform. Thomas Dreibholz
> Molbachweg 7
> D-51674 Wiehl-Forst Mail:
> dreibh AT exp-math.uni-essen.de
> Germany WWW: http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9muXw32BbsHYPLWURArILAJ467/ehe6ZteA2bet8bzInNNjew+gCcCp/R
> 0KKR48CcSRd/JoNOKSkDCgM=
> =eL13
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> rsplib-discussion mailing list
> rsplib-discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/rsplib-discussion
>





Archive powered by MHonArc 2.6.19+.

Top of page