More comments added inline. -- Al
> -----Original Message----- > From: Horvath, Elmer > Sent: Wednesday, May 30, 2007 5:18 PM > To: Nayman Felix-QA5535; Stephens, Allan; Randy Macleod > Cc: [email protected] > Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > Hi Felix, > > See inline below. > Elmer > > > -----Original Message----- > > From: Nayman Felix-QA5535 [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 30, 2007 4:51 PM > > To: Stephens, Allan; Horvath, Elmer; Randy Macleod > > Cc: [email protected] > > Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > > > Thanks for the response. Unfortunately, I don't think its feasible > > for us to use connection-oriented messaging > > > > A related question. What, if any, are the drawbacks or > performance > > issues to increasing the importance level of a socket to > medium, high, > > or even critical from low? > > Using a high level of importance will allow more messages to > be sent and queued on various sockets. The positive impact > will be that more of your messages will get through. The > negative impact will be a higher usage of resources and you > may end up starving out other sockets from queuing messages. Elmer has summed it up pretty well here. > > > After looking through the programmer's guide again, I think the > > section on message consumption and rejection with regards > to reaching > > the per-node socket congestion limit is misleading. From a strict > > reading of those sections, it would appear to me that if the > > destination droppable setting is disabled, TIPC should send that > > message back to the sender (and in a sense I guess it is). > Maybe this > > calls for a note to clarify this situation and say that if the > > per-node socket congestion limit has been reached, the > message shall > > just be dropped because it cannot be put on the original sender's > > receive queue. > > You may have a point here. The documentation does state > (under the "THINGS TO REMEMBER:" section in Message > Rejection) that "the non-return a message does not indicate > that is was successfully consumed". So the application must > be able to handle not getting a returned message even when > things go wrong. A clarification can be added here. However, we need to be careful about the wording we use because there *are* cases where a message may be returned successfully to the sender when the per-node socket congestion limit has been reached -- such as when the sender and destination are on different nodes. > > > Is there something wrong with the tipc-discussion list? I keep > > getting Internal Server errors while trying to access > various postings > > and it is otherwise very slow and has been this way for at > least the > > past few days. Also, the link from > > http://tipc.sourceforge.net/support.html to view archived > postings is > > broken. > > I also got an error just now. Not sure what is up there. I suspect that the SourceForge site is undergoing one of its periodic hiccups. Over the last few months I've encountered a number of indcidents when the mail server there takes a long time to broadcast messages to the TIPC mailing list and/or sends out multiple copies of certain posts (sometimes days or even weeks after the original posting!). I suspect that this isn't something that is site-wide and impacts more than the TIPC project team. > > > Thanks, > > Felix > > > > > > -----Original Message----- > > From: Stephens, Allan [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 30, 2007 3:21 PM > > To: Nayman Felix-QA5535; Horvath, Elmer; Randy Macleod > > Cc: [email protected] > > Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > > > Hi Felix: > > > > If you use connection-oriented communication between your > clients and > > servers then TIPC will automatically block the client from sending > > messages to its server once more than about 1000 messages > accumulate > > at the server end, which will help prevent a single non-responsive > > server from consuming too many resources. However, this really > > doesn't help a whole lot since it is still possible for multiple > > non-responsive servers to hog all of the allowable message > buffers in > > their receive queues; nor does this help if you really need to use > > connectionless messaging. > > > > So, at the moment, I think it's left up to the applications > using TIPC > > to do the necessary work to ensure that they don't choke the system > > with too many messages. There has been some discussion on this > > mailing list over the last couple of years about what might be > > desirable to provide a better way of dealing with congestion and to > > provide better quality of service (QoS) characteristics (such as > > Randy's request to make the socket receive queue thresholds > > programmable), but so far no one has stepped forward to actually do > > any work in this area. > > > > -- Al > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Nayman Felix-QA5535 > > Sent: Wednesday, May 30, 2007 2:27 PM > > To: Horvath, Elmer; Randy Macleod; Stephens, Allan > > Cc: [email protected] > > Subject: Re: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > > > Guys, > > > > Thanks for the replies. What Al mentioned is exactly what's > > happening. > > > > The real issue from our product's point of view is to have a way to > > detect that we're in a congestion situation for either one > socket or > > more importantly, per-node socket congestion. Is there a way to > > detect that this is happening? > > > > Thanks, > > Felix > > > > > > -----Original Message----- > > From: Horvath, Elmer [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 30, 2007 1:09 PM > > To: Randy Macleod; Stephens, Allan > > Cc: Nayman Felix-QA5535; [email protected] > > Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > > > 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 > > > ------------------------------------------------------------------------- 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
