On Tue, 2010-01-26 at 12:59 -0500, Scott Lawrence wrote: > > If a message can't be sent to a queue because it is full, this message > > is logged: > > > > OsSysLog::add(FAC_KERNEL, PRI_CRIT, > > "OsMsgQShared::doSendCore message send failed for > > queue '%s' - no room, ret = %d", > > mName.data(), ret); > > > > If a message is sent to a queue and the queue is over half full, this > > message is logged: > > > > OsSysLog::add(FAC_KERNEL, PRI_CRIT, > > "OsMsgQShared::doSendCore message queue '%s' is over > > half full - count = %d, max = %d", > > mName.data(), count, max); > > PRI_CRIT is too severe a level for that one - it probably should only be > a warning. We want it to be true that _every_ CRIT level log entry is > some problem that must be tracked down, and while this may be rare, it > might not be fatal or even a big problem.
Yes, I was lazy when I set both those messages to CRIT. I've gone back and looked at the definitions of the logging levels, and I've revised the "queue full" message to ERR, and the "over half-full" message to NOTICE. (The reason I set "queue full" to ERR is that the detected condition doesn't affect any request other than the one that failed. If the queue stays full, there will be a string of ERR messages, one for each failed request, which should be noticeable.) > What is 'ret' going to be? 'ret' is the return value from the semaphore acquire operation, which shows how it failed. It's not a user-friendly value, but it is the information you need when you're looking at the code. > > Systematically logging situations where queues are not nearly empty can > > point out potential bottlenecks. > > ... or create them, if logging affects the timing... It's true that there is that risk. But we haven't had problems with logging causing delays that I've heard of. > > - It's not clear that the concept of "queue size" is useful. sipXecs is > > not limited by memory consumption, so there doesn't seem to be a reason > > to worry if, say, 1000 requests get queued for a task. > > I'm not sure I agree with that... I've found some pretty serious design > errors that first manifested as a queue overflow. And Robert agrees with you here. So I think I'm convinced that queue limits are useful as a means for keeping us honest. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
