First login?
Lost password?
 
 
rsplib-discussion AT lists.franken.de 
RSPlib Discussions

Text archives Help


Re: [RSPlib-Discusssion] fail-over problems


Chronological Thread 
  • From: Thomas Dreibholz <dreibh AT irmgard.exp-math.uni-essen.de>
  • To: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>, <rsplib-discussion AT sctp.de>
  • Subject: Re: [RSPlib-Discusssion] fail-over problems
  • Date: Mon Sep 23 15:42:01 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>
  • Organization: University of Essen, Institute for Experimental Mathematics
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Montag, 16. September 2002 11:46, Marjan Bozinovski wrote:
> Hi Thomas,
>
> In the logfile I sent you on Friday, one can see that the problem occurs
> with the rspSelect(). These are the suspicious debugging output line:
>
> -----------------------
> 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
> select: wake-up
> ----------------------
>
> It's strange, there is Data Arrive Notification, but rspSelect() returns
> zero. What is the problem? This does not happen when examplepu is run.
>

I was on holiday, without laptop and Internet access, therefore the late
reply.

In the logfile, the ext_select wake-up seems to be caused by the data
arrival.
To be sure it is not the select timeout, set timeout.tv_sec to a very large
value first and check it.

In case the select wake-up is correctly caused by the data arrival, there
must
be a read condition. This is checked about line 2620 in sctpsocketwrapper.cc.
Use the following code here:

int changes = 0;
for(cardinal i = 0;i < selectData.Conditions;i++) {
if(selectData.ConditionArray[i]->fired()) {

// NEW
printf("Condition %d (Type %d, FD %d)
fired!\n",i,selectData.ConditionType[i],selectData.ConditionFD[i]);
// ---

changes++;
switch(selectData.ConditionType[i]) {
...
}

// NEW
else {
printf("Condition %d (Type %d, FD %d) not
fired\n",i,selectData.ConditionType[i],selectData.ConditionFD[i]);
}
// ---


selectData.ConditionArray[i]->removeParent(selectData.ParentConditionArray[i]);
}


Now, uncomment line 48 in condition.cc (#define PRINT_SIGNAL); this will
print
out some debug information about the conditions. Use "gmake clean" and "gmake
install" to ensure complete recompilation and reinstallation of the changed
socket API code. Then, recompile rsplib with "gmake clean" and "gmake".

My idea for the problem is that possibly somewhere the read condition's
"fired" state is lost and therefore the readfd will not be set. The next
logfile will hopefully locate it.


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

iD8DBQE9jxeQ32BbsHYPLWURAr8KAKCM3Dqon2NwgHcFnK349ZDko8xYsgCgq0Z3
0ZBa7PEou9E4Acd7SR2/HsY=
=wLDC
-----END PGP SIGNATURE-----



Archive powered by MHonArc 2.6.19+.

Top of page