Hi, I would actually say that the data itself is more important than getting a message (that may or may not make it through to the sender depending on many factors). In that event, shouldn't the returned message be sent at: original importance - 1
Just playing devil's advocate. Elmer Randy Exclaimed: >Stephens, Allan wrote: >> Hi Felix: >> >> The results in case 1) are to be expected since you are running your >> client and servers on the same node. What is happening is that the >> messages to the server are still being rejected, but are not being >> queued up on the client's receive queue because this would exceed the >> 5000 message per node limit. (That is, the same mechanism that prevents >> the messages from reaching the servers also prevents them from returning >> to the client.) > Does this design seem reasonable? > Shouldn't message replies indicating: "I'm full/busy" be sent at: > original importance + 1 > // Randy I would actually say that the data itself is more important than getting a message (that may or may not make it back to the sender depending on many factors). In that event, shouldn't the returned message be sent at: original importance - 1 Just playing devil's advocate. ;) Elmer > > The results in case 2) probably make sense for the same reason. What is > probably happening here is that messages are rejected by one of the > servers once it's queue reaches 2500, but before the other server's > queue has reached that limit; consequently, some rejected messsages make > it back to the client and are consumed, allowing things to continue > until the clients have sent 12000 messages. However, once both servers > reach the 2500 message limit, the scenario becomes identical to that in > case 1) and no further rejected messages are received by the client. > > Regards, > Al > > ------------------------------------------------------------------------ > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of > *Nayman Felix-QA5535 > *Sent:* Wednesday, May 30, 2007 12:14 PM > *To:* [email protected] > *Cc:* Horvath, Elmer > *Subject:* [tipc-discussion] Dropped messages in TIPC 1.5.12 > > Since I didn't get a response to my previous post, I'll try to make this > post easier to read and answer. > > I've noticed two things while running various congestion tests where a > server is not pulling messages off of its receive queue: > > 1)When I reach the 5000 per node socket-based congestion limit after > doing the following: > a)running one server/client pair and filling up that server's receive queue > b) then start a second server and fills up its receive queue using the > same client > c)messages are no longer rejected back to the client once I reach the > 5000 message count, instead they appear to be just dropped. Is that > behavior expected? > > 2)When I've got 2 servers running without pulling messages off of their > receive queue (regardless of whether or not they have the same TIPC > Name). I see no rejections whatsoever after sending over 12000 > messages. The messages appear to just get dropped. Why? > > I'm running TIPC 1.5.12 on a 2.6.9 linux kernel with connectionless > traffic on the same node with the domain set to closest first and the > destination droppable flag set to FALSE. I'm running modified versions > of the hello world demo client and server programs for this testing. > > Let me know if you need anymore information. > Thanks in advance, > Felix > ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
