Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-12221

irc flood control

    XMLWordPrintable

Details

    Description

      currently if commit message consists of several lines, the bot submits then instantly to channel and mostly gets kicked out of server due flooding

      14:38:07 jenkins [PircBotX@=qZcvkzqw.delfi.net] has quit [Excess flood]

      Attachments

        Issue Links

          Activity

            whimboo Henrik Skupin added a comment -

            What I see is somewhat related to flood protection but not for messages. As it looks like the bot is setting itself too often as being away:

            Jan 21, 2014 5:28:22 AM hudson.plugins.ircbot.v2.PircListener onServerResponse
            WARNING: IRC server responded error 429 Message:
            jenkins-bot :Too Many aways - Flood Protection activated

            whimboo Henrik Skupin added a comment - What I see is somewhat related to flood protection but not for messages. As it looks like the bot is setting itself too often as being away: Jan 21, 2014 5:28:22 AM hudson.plugins.ircbot.v2.PircListener onServerResponse WARNING: IRC server responded error 429 Message: jenkins-bot :Too Many aways - Flood Protection activated
            kutzi kutzi added a comment -

            There's a delay of 0.5 secs after each line if I remember correctly, but there's no further flood control.
            Cutting the response after a certain amount of lines and incrementally growing the the delay (I think exponentally is a bit harsh) sounds like a good idea.

            kutzi kutzi added a comment - There's a delay of 0.5 secs after each line if I remember correctly, but there's no further flood control. Cutting the response after a certain amount of lines and incrementally growing the the delay (I think exponentally is a bit harsh) sounds like a good idea.

            imho two things should be implemented:

            1. control how many lines of commit message is passed, the rest is truncated (default 2-3?)
            2. control how often each line is sent to avoid getting excess flood messages (2-3 lines immediately, after that add delay 1s, after 5 lines change it to be bigger, delay *= 2, and so exponentally grow the delay?)

            but from your question i understand flood control is already implemented? just it got exceeded for me?

            glen Elan Ruusamäe added a comment - imho two things should be implemented: 1. control how many lines of commit message is passed, the rest is truncated (default 2-3?) 2. control how often each line is sent to avoid getting excess flood messages (2-3 lines immediately, after that add delay 1s, after 5 lines change it to be bigger, delay *= 2, and so exponentally grow the delay?) but from your question i understand flood control is already implemented? just it got exceeded for me?
            kutzi kutzi added a comment -

            Could you please clarify what you're exactly asking for? Should the delay between single messages be configurable or what?

            kutzi kutzi added a comment - Could you please clarify what you're exactly asking for? Should the delay between single messages be configurable or what?

            People

              kutzi kutzi
              glen Elan Ruusamäe
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: