Quoting Kev <[EMAIL PROTECTED]>: > You seem to have fubar'd flood throttling. Here's what I see in beta49: > > I get on the server. I manage to get all messages queued up *from* me > sent on by waiting a while, sending something to the server, etc., until > my ping time is 0 seconds. Now, I'm on #coder-com, so I paste in 10 I tried this an as expected it was slowly sending out one message at a time. I tried this both as an IRCOp and also while I was -o, on both current cvs .12 and current cvs .11. It could be platform dependent(I did this on: Linux central.mwn 2.4.18 #9 SMP Mon May 20 19:51:21 NZST 2002 i686 unknown using the poll engine). > "/mode #coder-com" commands. I get 5 responses. I wait a few minutes-- > nothing more. From another client, I send a message to the channel--I > see it in my hung client. Now I send a PRIVMSG to the channel--I get > 5 more responses from the "/mode #coder-com", but my PRIVMSG is not > seen. I wait a little longer, then send another one. Both PRIVMSGs > appear on the channel at once. > > This looks like either the client process timer isn't getting added when > it's supposed to or it's not getting processed correctly. A look at my > debug logs suggests that the client process timer is indeed getting > added, but perhaps it's not getting re-added when it's supposed to. I > know I had to really play with the packet processing code to get this to > work correctly; I figure your recent changes upset it somehow. Can I get > you to take a look at this and try to fix it? I shouldn't have changed the flow path at all for normal clients under any circumstances, so perhaps this problem was there before my patches, it could possibly be the cause of the dbuf_put fails, which I believe only happen on FreeBSD/kqueue, which could explain why you can see this problem and I can't. > > (And please do bump the patchlevel when you manage to get it fixed ;) > -- > Kevin L. Mitchell <[EMAIL PROTECTED]> > >
